Leo Famulari transcribed 3.2K bytes: > On Sat, Jul 01, 2017 at 05:36:04PM +0000, ng0 wrote: > > (This is brief and incomplete, just the way I see it right now) > > [...] > > > imagine that _before_ commits end up in master we build a set of > > virtual systems which at least must: > > > > - be build successfully > > - run through the initrd > > - briefly see the login manager > > > > We then need guidelines which commits are classified for building > > on which set of test machines. > > Finally the commit must be approved by more than 1 person and > > commited. > > > > There are odds and scenarios we can not test, but what we can > > test we should test. > > Stability must not be an enterprise feature (as it was mentioned > > in the past), it is expected by people who don't want to waste > > time with developing. Even reporting bugs is only done by those > > who bother to do so or are able to. I have more to add to the > > reasons when I can send out an longer email, this is just a bit > > of an impulse. > > First, is there some outstanding bug that needs to be fixed? It's > frustrating to get messages like this without any context.
Yes, but I certainly will not run reconfigure on here from HEAD again. When I ran into this I had not git setup, now I have. So someone else must do this. > I agree that we should strive to make the master branch more reliable. > > However, it must be understood that the main Guix contributors are > almost always *at the limit* of how much time and energy they can spend > on Guix. Sure, hence the disclaimer "brief" on the top. I will write a longer text later this month to get more into detail about my ideas. > Adding rules like requiring somebody else to test and approve a change > is unrealistic, since we can barely do what we do now. This suggestion > is basically equivalent to adding things to the patch review queue. > > As for automated QA, our build farm is also almost always operating at > its limit. This is an easier problem to solve, because we can spend > money to increase the capacity. However... > > > 0: What is it these days? Is hydra now just a in-retirement frontend > > for cuirass or how does bayfront work these days? I understand cuirass, > > not hydra. > > ... Bayfront is still not fully operational, so hydra.gnu.org is still > serving as the front-end of the build farm. We are still relying on the > Hydra software. That is, the situation is basically the same as before. > Adding build machines will not help very much until the front-end > hardware gets faster. So you're basically saying: yes good idea, I agree but this is too much presure on too little capacity in people and machines and we can not do any of this any time soon. Or did I miss something? -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org
signature.asc
Description: PGP signature
