[Ksummit-discuss] [MAINTAINERS SUMMIT] Bug-introducing patches

Tony Lindgren tony at atomide.com
Wed Sep 12 13:59:55 UTC 2018


* Guenter Roeck <linux at roeck-us.net> [180912 13:42]:
> On 09/12/2018 05:36 AM, James Bottomley wrote:
> > 
> > Look, shit happens occasionally.  What then happens is that you get a
> > note from Stephen saying your tree is dropped for a day for crapping on
> > the carpet and you fix it.  -next still builds without you so I don't
> > get what all the fuss is about.  From my point of view the -next
> > process works very well and I don't see a need to complicate it with a
> > -next-next or a -pre-next or whatever.

Fine so I trust James and many maintainers to do proper testing before
next. And I do testing too for the stuff I queue. And in many cases the
damage is quite limited in case of issues.

But then we have constant stream of patches that affect everybody and cause
regressions that don't seem to have much testing done on them before they
hit next.

> Not sure if I agree with the "works very well" part. I would say it works,
> for the most part, decently well, and we would be in a much worse situation
> without it. I would hope for code in -next to be tested a bit better,
> and problems to be fixed faster, but one can not have everything.

I think we can do much better. If we get next into usable shape then more
people will use it for testing. And then the -rc cycle becomes easy as
things have been mostly done already in next. Well, at least for me the
-rc cycle is now much easier after doing constant testing with next.

After all, next is really our common development tree, right? :)

So "How to keep Linux next working and usable continuously" might actually
be a somewhat constructive topic to dicuss.

> However, I definitely agree that we don't need -next-next or -pre-next.
> That would not improve the situation at all; it would just create even
> more noise and result in people testing their code even less before
> publishing it.

We could still establish a standard naming for "please-test-me" type
branches. Then we would at least provide a trigger for the test scripts
to go test them.

Regards,

Tony


More information about the Ksummit-discuss mailing list