Re: 2.6.19 -mm merge plans

[Russell King]

On Sun, Sep 24, 2006 at 09:48:37AM +0200, Lennert Buytenhek wrote:
> On Fri, Sep 22, 2006 at 09:21:32AM -0700, Linus Torvalds wrote:
> > I personally prefer to not see _too_ many pull requests, since that
> > to me indicates that people don't take advantage of the distributed
> > nature of git, and don't let things "simmer" in their own tree for
> > a while.
> 
> Changes that span sub-architectures (such as genirq) are usually
> discussed on the mailing list first, and tested before they get
> committed to any tree.  I.e. on the few occasions that we do need
> to test ARM-wide changes, we just email patches around rather than
> asking folks "whether 2.6.30-rmk42 works."

Let's look at how two scenarios work for the case of the genirq patches.

1. genirq remains as patches until it's ready (iow, what actually happened)
   - patches as a series were posted to the mailing list with a request
     to test.
   - feedback came, the patches were improved, and this repeated several
     times
   - eventually, people are happy
   - in parallel, because these patches affect other architectures, they
     were also submitted to -mm.
   - the generic parts of genirq were submitted to Linus.
   - once the generic parts of genirq are in mainline, the ARM specific
     parts can then be applied to my git tree, and be sent to Linus.

2. genirq patches in ARM git tree.
   - the initial entire patches get applied to the ARM tree on a
     separate branch.
   - the patches get mailed to the ARM mailing list as one large patch.
   - feedback comes to me/mailing list rather than CC:'d to the genirq
     people.
   - maybe the genirq people send updates to me, which then need to be
     applied to the ARM tree, and the result needs to be re-published.
   - we go around the loop several times, maybe merging in later mainline
     versions.
   - in parallel with this, the non-ARM parts of genirq are submitted to
     -mm.
   - when the patches are ready, the generic parts are submitted to
     Linus.
   - rmk then faces a _big_ problem in resolving lots of conflicts in
     his tree, because the generic parts submitted to Linus are different
     from the initial generic parts committed to the ARM git tree.
   - the ARM git tree for genirq probably has to be rebuilt from scratch.

Sure, someone else _could_ maintain genirq in their own git tree, so
replace "rmk" above with "tglx".  The overall problem remains though -
at the end of it you can't push that git tree with all that history,
and the whole thing can't go via just one person.  This in turn means
that there's a chunk of additional work to rework the changes (which
may introduce bugs) and then an additional round of re-testing to make
sure nothing broke.

The point I'm making is that for some things, keeping the changes as
patches until they're ready is far easier, more worthwhile and flexible
than having them simmering in some git tree somewhere.

> For example, a driver for the ethernet MAC in the ARM cpu that I have
> here was recently applied by jgarzik, but I cannot submit the arch/arm
> hooks to make use of this driver until jgarzik's tree is merged upstream
> _and_ rmk rebases the half a megabyte of pending ARM changes on this
> tree.  If I submit the hooks to rmk when the driver goes upstream, rmk's
> private tree (probably still based on 2.6.18 when that happens, so won't
> have the relevant netdev changes) will break.
> 
> To make making these kinds of changes easier without sending stuff
> upstream so regularly, rmk would have to either pull from upstream
> regularly or rebase his tree on upstream regularly, both of which
> don't seem like desirable options.

I believe that Linus has complained to tree maintainers when they've
done this because it complicates the history far too much.

Consider the effect on the history if I were to pull Linus' tree daily
into my trees, and I was committing about one change per day.  You'd
have:

linus---othercommits--------othercommits---------othercommits-------merge
  \           \                    \                    \          /
 commit --- merge --- commit --- merge --- commit --- merge --- commit

The other solution is that I somehow start reviewing drivers for any
part of the kernel and accepting them.  However, as we've seen already
on lkml, if anyone who isn't jgarzik accepts a change to a network
device driver and passes it to Linus, they get a roasting from Jeff
(see Dominic's incident when adding some additional PCMCIA IDs to PCMCIA
network device drivers.)


>From the point of view of keeping an ARM tree, I've been in that situation
before - from the beginnings of ARM support on Linux until the advent of
bitkeeper.  This was when I had my own tree which was published regularly.
The problem that posed is that the tree was seen as "the ARM tree" where
_everything_ to do with ARM (be it device drivers) was _dumped_.  Once it
was in there, the original authors decided that their job was done and
walked away.

The result was that I accumulated almost 1MB of compressed patch, and
we _never_ got to the situation where the merged ARM mainline was in
a buildable state despite _years_ of work to try to get it there.  The
closest we got was one of the 2.4-ac trees, just before Alan quit doing
them (which might have been a contributary reason.)

To date, none of the 2.4 trees is buildable for ARM.

The biggest problem with it is synchronising changes with other trees,
and persuading other people to submit things to the relevant people.
Either such a tree accepts the ARM specific bits along side the device
drivers (and then ends up with a review and bypassing other maintainers
problem, resulting in the tree owner getting regularly roasted) or
they get moaned at for not accepting device driver patches which are
dependent on other changes in that tree.

Since then, I've vowed to _never_ maintain such a "community" tree ever
again.  I credit 2.6 being buildable for ARM entirely on the choice to
get rid of this tree.

-- 
Russell King
 2.6 ARM Linux   - http://www.arm.linux.org.uk/

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