Re: 2.6.19 -mm merge plans

[Dave Jones]

On Fri, Sep 22, 2006 at 09:35:42AM +0100, Russell King wrote:
 > On Thu, Sep 21, 2006 at 06:05:39PM -0400, Dave Jones wrote:
 > > We already have some subsystems that do once-per-release merges,
 > > and then let fixes build up in their out-of-tree SCM for months
 > > until the next window. It won't necessarily get worse, but unless
 > > everyone is participating in the odd/even rules, we won't get
 > > the benefits that it would offer.
 > 
 > I'm heading in that direction (once-per-release merges) actually.
 > 
 > On one hand, I'm credited with the ARM architecture being one of the
 > best maintained embedded architectures in the kernel tree.  On the
 > other hand, that appears to be winding Linus up due to the regular
 > merge requests, which were happening maybe once or twice a week.

Hmm. Some trees do seem to get pulled more often than others.
Linus, is there a upper limit on the number of times you want
to see pull requests? It strikes me as odd, so I'm wondering
if there are some crossed wires here.

 > As far as -mm getting these, I have asked Andrew to pull this tree in
 > the past, but whenever I rebase the trees (eg, when 2.6.18 comes out)
 > and fix up the rejects, Andrew seems to have a hard time coping.  I
 > guess Andrew finds it too difficult to handle my devel branches.

Has Andrew commented on why this is proving to be more of a problem?
I've done regular rebases of cpufreq/agpgart (admittedly, they don't
reject hardly ever unless Len has ACPI bits touching cpufreq) without
causing too much headache.

 > So, what I'm going to be doing this cycle is essentially sitting on
 > stuff for quite some time and not really caring about where in the
 > release cycle mainline actually is. 

That doesn't sound like the right way to fix the 'caring for my Linus' problem :)

 > As far as my future, I will be handing MMC off to Pierre Ossman during
 > this cycle (there are other reasons for doing this which Pierre has been
 > aware of for some time.)
 > 
 > I'll also be dropping my serial tree entirely - I have no idea who could
 > stand in for serial, so there's going to be no real "hand over" for that.
 > I do have some outstanding in-progress changes which aren't really ready,
 > but those will probably end up in /dev/null (in much the same way that my
 > in-progress changes for PCMCIA ended up in a similar place when I handed
 > that tree over.)

That's unfortunate. If you want someone to scoop bits up and feed Linus,
I'm happy to volunteer for the task, as long as you're still willing
to eyeball serial diffs until I get up to speed.

	Dave 
-
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/