[Ksummit-2012-discuss] [ATTEND] structuring of tools et.al and linux-devel.git repo
James.Bottomley at HansenPartnership.com
Thu Jun 21 07:43:20 UTC 2012
On Wed, 2012-06-20 at 20:00 -0700, Paul E. McKenney wrote:
> 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. ;-)
Exactly. It's not about preserving history at all costs, nor about
rebasing at every opportunity for maximum cleanliness. The warts and
all history of how a particular patch set wound up in its accepted form
is interesting to historians but incredibly frustrating to people trying
to track down bugs (or even back port the feature). A patch series is
like a paper submission ... it should allow others to follow what you
did easily, not exactly as you slipped up on the way; it should be
polished and not riddled with corrections and rewrites that make it hard
to read. So anyone preparing a patch series should feel free to rebase
it to make it better right up to the time they submit it. After it's
published, it still gets reworked for comments, so the point at which it
stops being rebased is when it gets to a maintainer tree.
In general no maintainer would ever accept an email patch series that
breaks bisectability, so I won't accept a git tree that does either
(notwithstanding whining about history preservation). The area starts
to become greyer after I've accepted the patch set and then a
bisectability break turns up because of some config combination I didn't
test. My usual rule is that unless I've already sent a pull request to
Linus, I'll rebase to fix it.
More information about the Ksummit-2012-discuss