Message-ID: <20091024080326.GA7461@mit.edu>
Date:	Sat, 24 Oct 2009 04:03:26 -0400
From:	Theodore Tso <tytso@....edu>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Nicolas Pitre <nico@...xnic.net>,
	"Luck, Tony" <tony.luck@...el.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	"Luis R. Rodriguez" <mcgrof@...il.com>,
	Jeff Garzik <jeff@...zik.org>,
	Robert Richter <robert.richter@....com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC] to rebase or not to rebase on linux-next

On Fri, Oct 23, 2009 at 10:54:00PM +0200, Ingo Molnar wrote:
> 
> * Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > Here's the basic gist, some people believe that linux-next is used as 
> > a dumping ground for their repos that get rebased all the time. They 
> > use linux-next for early testing, and mostly to make sure their repo 
> > will not collide with other developers repos.
> 
> I see signs of such an attitude, and i think it's somewhat harmful.
> 
> As far as using linux-next for a test-and-rebase workflow - IMO 
> maintainer trees should lead with a good example and should not push 
> 'avoidable crap that might need rebasing' into linux-next (knowingly at 
> least - there's enough unintentional damage) that they wouldnt push 
> upstream to Linus to begin with.

I think we need to be a bit careful in this discussion.  There are two
things that cause a particular git tree to be one which can't be used
as a the basis for subtrees.  One is "rebasing", where a series of
commits is dropped onto a new version, or base, hence "rebasing".  The
other is where one or more commits are *modified* --- perhaps to add
ack-ed by, or tested-by comment lines, or to improve comments, or to
fix outright bugs in the the patch series.  Perhaps it's better to
call this "rewinding", since in most cases this doesn't actually cause
a change in the "base" of the patch series.

The reason why it's important to make this distinction is that some of
the arguments about why constantly changing the base of a patch series
don't apply when we are just fixing up patches in the patch series or
git tree.

So given that, why do I think "rewinding" has a place as a development
methodology for patch sources that feed into linux-next.

1) Linux-next is by definition a constantly rewinding branch.  It is
thrown away and recreated every day, based on the tip of Linus's
mainline tree, and so the date of the merge commits means that you can
never base anything on top of linux-next.  This has always been the
case, and so trying to impose a straightjacket on all of the sources
of linux-next doesn't actually buy anything as far as the properties
of linux-next.

2) There are many legitimate reasons for "rewinding".  In addition to
being able to add credit for tested-by and acked-by lines, sometimes
patches are subtle.  More than once, patches have been sitting in the
ext4 tree that have passed the XFSQA test, and thus have been "unit
tested", but they still have bugs; in some cases, subtle bugs.  In
some cases, bugs that cause data corruption.  In the case where the
patches have hit linux-next, but the merge window hasn't opened yet, I
prefer to fix the patch by mutating it, and rewinding the ext4 tree,
instead of adding a fix later.  It makes it easier to cherry pick
patches to the stable tree later, and it keeps the ext4 tree clean,
and it has no downside in terms of linux-next --- see (1) above.

3) I don't have the same access to vast amounts of hardware and
platforms that Ingo does.  As a result, while I make a practice of
testing every single patch against the XFS test suite (yes, it's slow
and painful, but I think it's worth it; I'm very paranoid about patch
quality), every once in a while the patch has warnings or doesn't
compile on some platform for which I don't have build/test machines.
Today, this gets tested in linux-next, and when it does, if it the
merge window hasn't opened yet, I will fix it the patch instead of
creating an extra patch.  This helps git bisectability for platforms I
don't have access to.

4) The practice of rewinding and updating patches has a long and
honored history.  It's the way Andrew Morton has worked with
linux-mm/mmotm, for example.  And many patch series sources for
linux-next.  One argument which Ingo has advanced is perhaps those
subsystems shouldn't use git at all, and just use patch series.  I
think this is nonsense.  First of all, it's more convenient to deliver
patches to linux-next and Linus via git.  Secondly, sending a git pull
request *does* provide more information than just a patch series.  The
git pull request includes one critical bit of information --- the base
version that the maintainer has tested against, and that is preserved
when patches are delivered via a git pull request.  If the ext4 tree
was delievered via a patch series, then by definition when the patches
are applied, they will be rebased, in the proper sense of the term,
and you get all of the evils about *rebasing* (as opposed to rewinding
and fixing up patches) that people have complained about.  

Ultimately, one of the things that Linus has said recently, both at
LinuxCon and again at Kernel Summit, is on the whole he's very happy
with how the development process has been moving, and one the things
that he has pointed at is linux-next.  So I'd argue, let's not break
something that is working quite well.  Whether or not a particular
subsystem uses patch series, a rewinding git tree (using tools like
guilt or stgit), or an append-only git tree, is currently up to the
maintainer and the circumstances of how many developers participate in
a particular subsystem, and whether subtrees would actually be helpful
for that particular subsystem.  I don't think we should be imposing
straightjackets on maintainers.  What works well for one subsystem may
not work well for others.  And again, on the whole, Linus has said
that he's very pleased with how things are working today.  So maybe we
should leave well enough alone, and not try to impose a procrustean
bed on all maintainers.

Regards,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists