[Ksummit-2012-discuss] [ATTEND] structuring of tools et.al and linux-devel.git repo

Paul E. McKenney paulmck at linux.vnet.ibm.com
Thu Jun 21 03:00:10 UTC 2012

On Tue, Jun 19, 2012 at 11:55:41AM -0700, Joe Perches wrote:
> On Tue, 2012-06-19 at 14:39 -0400, Steven Rostedt wrote:
> > On Tue, 2012-06-19 at 11:22 -0700, Joe Perches wrote:
> > > Well, perhaps git bisect could just be smarter
> > > about bisecting with reverted commits.
> > And may I ask what purpose would it be to have "what didn't work" in the
> > git history? To me, it causes more harm than being useful.
> > 
> > If it was tried and released, that's one thing. But if it was tried in
> > development and is proven to be broken, that's something else. Post
> > patches to the mailing and let the mailing list archive be the location
> > of what didn't work.
> That's an out-of-line location and isn't part
> of git history.
> > If you included 10 patches where the first one is reverted later, but
> > instead of rebasing and removing that patch and only submitting the 9
> > good ones, how would a git bisect work in such a case? If the bisect hit
> > patch 5, it would include the reverted commit.
> Not if git bisect was smarter about testing and/or
> ignoring reversions.
> I don't see any issue with people having private
> branches and not pushing things to -next.  I also
> just don't see an actual problem with -next as-is.
> Making stuff wait 6+ months for inclusion into
> a nominal master tree seems inefficient and
> needlessly slow.

That depends.  Some difficult RCU features have churned outside of
mainline for more than a year.  It made no sense to mainline them because
they were broken.  Not just that things broke with CONFIG_RCU_BOOST,
but that things were often broken without it as well.  Believe me, even
you would not want the full history of all the twists and turns of RCU
priority boosting in mainline.

Some stuff just takes a long time to get right, and we don't push such
stuff to mainline until it is ready.  And when we do push it to mainline,
we need to do so with a nice series of patches that can be reasonably
reviewed, not a trainwreck.  ;-)

							Thanx, Paul

More information about the Ksummit-2012-discuss mailing list