Re: stability of master - just QA and hydra is not enough

[ng0]

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