Re: emba.gnu.org overload

[Andrea Corallo]

Michael Albinus <michael.albinus@gmx.de> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Hi all,
>
> Hi Andrea,
>
>> I believe the right fix, instead of dropping configurations, would be to
>> have a decent machine to run on.  Can't we ask for more resources?  ATM
>> these are extremely limited to the point where even building few Emacs
>> instances is a problem.  Now days bootstrap time has been greatly reduced
>> even compared to when we added these builds to emba, I'm surprised to
>> see we cannot afford it.
>
> Yes, it would be better. But we don't have it, and we also don't have even
> somebody who could reinstiate a crashed gitlab runner on our second
> machine. That's also part of the current trouble.
>
>> My main worry (almost a certainty) is that once these configurations are
>> removed from the test-bed they will never be added again in the future
>> following the well known rule of: "Nothing is more permanent than a
>> temporary solution".
>
> Yes. You might have seen in my other message, that I have deactivated
> build-native-comp-speed1 and build-native-comp-speed2.
> build-native-comp-speed0 and test-native-comp-speed0 are still active,
> so we still have the basic tests for native compilation.

Hi Michael,

I think if we have to choose we should keep testing speed 2 and disable
0 and 1 and 3 (2 is actually the default).

Best Regards

  Andrea