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

James Bottomley James.Bottomley at HansenPartnership.com
Wed Sep 12 12:36:10 UTC 2018


On Wed, 2018-09-12 at 13:55 +0200, Geert Uytterhoeven wrote:
> Hi James,
> 
> On Wed, Sep 12, 2018 at 1:29 AM James Bottomley
> <James.Bottomley at hansenpartnership.com> wrote:
> > On Tue, 2018-09-11 at 16:22 -0700, Tony Lindgren wrote:
> > > * James Bottomley <James.Bottomley at HansenPartnership.com> [180911
> > > 22:58]:
> > > > On Tue, 2018-09-11 at 16:31 -0400, Steven Rostedt wrote:
> > > > > 
> > > > > Why not do what I do and push to a -pre-next branch when you
> > > > > kick off your local tests?
> > > > 
> > > > Because there's no point.  As I said, when we complete the
> > > > local criteria the branch is ready for integration.  We push to
> > > > -next and *all* the built bots tell us if there are any
> > > > problems (which I don't expect there are but there's room for
> > > > me to be wrong) ... including 0day.  I don't see what the delay
> > > > and the process hassle would buy us if we only get a review by
> > > > 0day in the -pre-next branch.  It seems more efficient to let
> > > > every bot loose on what we think is mergeable.
> > > 
> > > Well what we're after is providing a trigger for people writing
> > > test scripts to test individual branches before they get merged
> > > into next.
> > > 
> > > With the goal of trying to keep next usable constantly.
> > > 
> > > Establishing a branch naming standard like "-pre-next" would
> > > allow the scripts to test the various branches where available
> > > before they hit next and warn about issues.
> > 
> > I still don't get the purpose: as I've said several times, SCSI
> > pushes to -next when it thinks the patches are ready for
> > merging.  Almost none of the subsequently discovered bugs (by both
> > bots and humans) affect anything other than SCSI (and usually only
> > a specific driver) so there would have been no benefit to testing
> > them in a separate branch and indeed probably the detriment of
> > diverting resources.
> > 
> > That's my point: from my point of view the -next process is
> > actually working; I don't see a reason to complicate it.
> 
> Good. Then this discussion wasn't targeted to the SCSI people, but to
> other maintainers pushing brown paper bags and other trivial
> breakages they should have caught beforehand to linux-next ;-)

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.

James



More information about the Ksummit-discuss mailing list