Re: [gentoo-project] [RFC] Making "stabilization" a prerequisite to become a Gentoo Developer

[Rich Freeman]

(Apologies in advance if it seems like I'm picking on you.  I want to
make a point more than criticize you in particular, because I'm sure
your motivation is care and not impediment.)

On Thu, Oct 5, 2017 at 3:54 PM, Daniel Campbell <zlg@g.o> wrote:
>
> I don't arch test because (a) I don't use stable and (b) I don't want to
> mess something up.

And if everybody else does this then nobody will use stable, because
it will be messed up.  :)

> There are also too many ways to do arch testing and
> it's not clear which method is most reliable.

The problem is that we need people do do some testing.  If nobody
tests anything because nobody has found the "most reliable" way to
test things, then everybody will end up using completely untested
software by default.

IMO this is one of those situations where the perfect is the enemy of the good.

> chroots can be problematic
> since they have bound mounts to the host system and the interaction
> between systems can present false positives for issues, and are fragile
> to maintain. A VM comes with its own set of problems (drivers, I/O,
> admin overhead), and containers are a world all their own.
>

Obviously testing grub in a chroot isn't going to work.  However,
unless you're doing testing of drivers/kernel/bootloader/etc a chroot
will be fine for just about anything.  A container would be even
better, and the difference between a container and a chroot is about 2
shell commands.

> Perhaps arch testing would be more attractive if there was One True Way™
> to setup an arch testing system

I think arch testing would be more effective if people stopped
worrying about the One True Way and just did some arch testing, any
way they can.  Just about every stable keyword in the tree is the
result of this, and this is how it has always been on Gentoo.

The moment I post a suggested One True Way somebody is going to point
out one bug in the last 10 years that would have escaped detection,
and suggest that nothing should be keyworded until a rigorous 300 step
process has been run, featuring tinderboxes that nobody is bothering
to build, and automated tests that nobody is going to write.  Then
we'll bikeshed for six months about the pros and cons of 14 different
methods of tinderbox log analysis, and people will start wondering why
the subject line says something about stable keywords.  :)

> and higher level tools to facilitate bug
> interaction.

That would certainly be lovely, but it requires somebody to build
those tools, and I don't see that as a short term solution.

I think that encouraging devs to be a little less afraid of mistakes
is probably the right way to go.  There is a balance between paralysis
and running around just keywording everything in sight without even
bothering to build it.  If you get feedback that something broke just
do things a little differently next time.  The fact that some dev got
yelled at by QA because he ran some shell script that wrought havoc
upon the tree 6 years ago isn't a reason why everybody should be
afraid to make a good-faith effort.

If the Council wants proposals for a resolution to define for once and
all what "stable" means I can toss something out there.  Short of that
I suggest that the people actually bothering to keyword stuff are
going to get to write the rules...

-- 
Rich