Recent LWN articles on the linux-next tree have noted that, while this tree
has been working well in its role of identifying merge conflicts between
subsystem trees, it has not yet been through a full kernel development
cycle. 2.6.27 will be the first kernel release where linux-next was in
existence for the entire preceding cycle; in theory, everything which goes
into 2.6.27 should have been aged in linux-next first. As the end of the
2.6.27 merge window nears, a look at how linux-next has affected the
process seems warranted.
One might think that linux-next maintainer Stephen Rothwell would be able
to take a break during the merge window; it should mostly be a matter of
watching the linux-next tree drain into the mainline. As it happens, the
daily linux-next postings (example) suggest
a fair amount of scrambling to deal with merge conflicts, build failures,
and more. There are a number of reasons for this, one of which being that
subsystem trees are merged into the mainline in an order which is
completely unrelated to their order in linux-next. Patches which remain in
linux-next are being applied to a highly unstable base.
Another interesting phenomenon has been a fair number of patches appearing
in linux-next during the merge window. Some of these are actually patches
intended for 2.6.28; once maintainers have dumped their 2.6.27 patches into
the mainline, they are starting to acquire stuff for the next time around.
Stephen has asked them not to do that,
requesting that 2.6.28 material not be directed toward linux-next until
after the 2.6.27-rc1 release. The goal is that linux-next should be nearly
empty when 2.6.27-rc1 comes out.
Other patches, though, are intended for 2.6.27 but simply have not done
their time in the linux-next tree. That had led to a certain amount of
developer grumpiness at times. It is interesting to note, though, that one
of the biggest examples of linux-next avoidance - David Miller's merging of
the multiqueue networking code which he had finished writing hours before -
has generated relatively few complaints. But various other types of
conflicts have generated a steady steam of terse notes from Andrew Morton
(who is in the unfortunate position of basing his work on top of
linux-next) on how new stuff should have been in linux-next weeks ago.
Another area of, say, colorful conversation has been around the TTY
subsystem, currently been subjected to a much-needed thrashing by Alan Cox.
Some developers have been unhappy with Alan for merging code which failed
to compile, even though those problems had already been identified in
linux-next. Alan, instead, has become irritated with other developers who
have surprised him with TTY-layer changes of their own, causing Alan's
patches not to apply. Alan has some quaint notions about actually testing
his patches, so the resolution of this kind of conflict requires the
running of a new set of regression tests and such; after this had happened
a few times in a row, he started getting a little short-tempered. These issues
would appear to have been worked out at this point, but the idea behind
linux-next was to keep them from happening in the first place.
Yet another source of occasional merge issues is the rebasing of trees.
Rebasing, in git-speak, is the process of modifying the commit history in a
repository to cause a series of patches to look like they were written
against a later version of the code than they really were. Rebasing can be
a useful technique; it generates a series of patches which applies cleanly
to the current state of the tree without generating a bunch of unsightly
Rebasing can be especially useful in the context of linux-next. If testing
turns up a patch which breaks the build, simply committing a fix will leave
a period in the history where the kernel cannot be built, and that is bad
for people running bisections. With the use of git's history editing
features, the offending patch can be fixed in place and all evidence of the
mistake disappears. In essence, that embarrassing commit mentioning the
Eurasian campaign can be fixed up to properly note that we've always been
at war with Eastasia.
But rebasing a repository changes the history (by design), creating, in the
process, an entirely new set of commits. Those commits are new code, to
the point that any results from testing the older version may no longer
apply. The commits also have new names, so any other developer who was
using a version of the repository will be shaken off and unable to merge.
Issues related to rebasing have come up a couple of times during the merge
window, leading Linus to post a series of lectures on
the problems that rebasing can cause. It is clearly a tool which must be
used with restraint, but occasional use of rebasing can, in the linux-next
context, lead to a better final merge. Finding the right balance is
something each developer will have to learn.
In the end, the merge window remains a bit of an unruly time. The process
of channeling the work of several hundred developers into the mainline over
a two-week period is unlikely to ever be an entirely smooth experience.
But, for all its glitches, the 2.6.27 merge window has been (so far!)
easier than 2.6.26. The presence of the linux-next tree almost certainly
has something to do with that. This tree's role continues to evolve, but
its benefits are starting to be felt.
to post comments)