Gentoo Archives: gentoo-project

From: Daniel Campbell <zlg@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] [RFC] Making "stabilization" a prerequisite to become a Gentoo Developer
Date: Fri, 06 Oct 2017 08:14:51
Message-Id: 20171006081439.GA23456@clocktown
On Thu, Oct 05, 2017 at 04:18:42PM -0700, Rich Freeman wrote:
> (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.)
No worries. I appreciate the time spent to converse about it.
> > 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 >
Solid points, some I hadn't thought of. If I get the spare time, I'll consider setting up a chroot, even if its only for stabilizing packages I'm familiar with. In the aggregate, it could reduce testing burden over the long term. Thanks for giving me a reason to reconsider.

Attachments

File name MIME type
signature.asc application/pgp-signature