[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emba.gnu.org overload
From: |
Mattias Engdegård |
Subject: |
Re: emba.gnu.org overload |
Date: |
Tue, 6 Dec 2022 15:03:38 +0100 |
6 dec. 2022 kl. 14.43 skrev Andrea Corallo <akrl@sdf.org>:
> I believe the right fix, instead of dropping configurations, would be to
> have a decent machine to run on.
We all agree on that but such things take time, and having some useful CI
capability right now is better than none at all.
In fact, all experience tells us that a project draws great benefit from stable
and reliable CI -- the baseline is green and when build or test errors occur
they stand out and are swiftly remedied.
Conversely, as soon as random failures start to pop up, whether by overload,
unstable tests or bad hardware, people become less inclined to look at look at
them, and actual errors aren't spotted early or at all. This remains true to
some extent even when overloading just causes delays, not outright failures.
In other words, we are better off keeping the builds reliable, even if that
means cutting some things we'd rather have. On the bright side, it tends to
focus minds on making things go faster, and forces some healthy prioritisation.
Not everything is equally important.
- Re: emba.gnu.org overload, Michael Albinus, 2022/12/05
- Re: emba.gnu.org overload, Mattias Engdegård, 2022/12/05
- Re: emba.gnu.org overload, Andrea Corallo, 2022/12/06
- Re: emba.gnu.org overload, Michael Albinus, 2022/12/06
- Re: emba.gnu.org overload, Andrea Corallo, 2022/12/06
- Re: emba.gnu.org overload, Michael Albinus, 2022/12/07
- Re: emba.gnu.org overload, Andrea Corallo, 2022/12/08
- Re: emba.gnu.org overload, Michael Albinus, 2022/12/09