[lkml]   [2009]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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;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
-=====-==--= =-=- ==---

 \ /
  Last update: 2009-10-24 14:23    [W:0.172 / U:2.292 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site