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

[Leo Famulari <leo@famulari.name>]

[-- Attachment #1: Type: text/plain, Size: 2194 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.

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.

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]