Messages in this thread |  | | | Date | Sat, 24 Oct 2009 14:20:06 +0200 | | From | Stefan Richter <> | | 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/
|  |