Date:	Sat, 24 Oct 2009 14:20:06 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Theodore Tso <tytso@....edu>
CC:	Ingo Molnar <mingo@...e.hu>, 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>,
	Sam Ravnborg <sam@...nborg.org>
Subject: Re: [RFC] to rebase or not to rebase on linux-next

Theodore Tso wrote:
> 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.

That's helpful terminology.

> 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.

Though per definition of what is expected to be submitted into
linux-next, both rebasing and rewinding should occur rather rarely.

Instead of a process rule that for-next branches should not be rebased/
rewound, I would suggest that
    If a for-next branch is rarely rewound, let alone rebased, it is an
    indicator that development and maintenance of a tree are going well.
    And vice versa.
stands as a /rule of thumb/.  Actually, that's all very obvious because
a for-next branch is pretty much a /release/ branch.

> 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

[It is not entirely thrown away, see
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=tags. But
it is indeed recreated daily, i.e. next-N does not include the end
result of next-N-1.]

> 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

Per linux-next submission rules, all /essential/ credits are already
present.  But I agree that it is worth rewinding a for-next branch in
order to add (non-essential) credits later.  linux-next's exact history
is of interest for days or months at most, while mainline's history is
of interest for many years to come.

> 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.

We should rely less on linux-next as a cross-compile farm; that's not
its purpose.  We can cross-compile ourselves.  I think the documentation
and toolchain can be found somewhere.  In fact, we are supposed to do so
per item 3 in Documentation/SubmitChecklist.  This text was added about
two years before linux-next opened for business.

That said, I admit that I don't test more than x86-64 myself (x86-32
too, but decreasingly frequently now).  But that's mostly because I only
deal with code where the danger of architecture-dependent build breakage
is very low.  (drivers/ieee1394 is frozen, and drivers/firewire is
small, modern, sparse-clean, and uses clean interfaces to the rest of
the kernel.  There is some more danger of /runtime/ regression of these
drivers on other architectures, but those would only be exposed in
mainline or distributions, not in linux-next already.)  I guess on the
unlikely day that I get notice of a linux-next build bug due to my tree
on one of those platforms, I will reorder my never ending to-do list and
set up local cross compilation.
-- 
Stefan Richter
-=====-==--= =-=- ==---
http://arcgraph.de/sr/
--
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