RE: merge status

RE: merge status

[Brown, Len]

>-rw-r--r--    1 akpm     akpm       188863 Nov  9 11:29 git-acpi.patch

FreeBSD found some problems with some of the post 2.6.14
ACPI core changes, and the version we have in 2.6.14 seems
pretty stable, so I'll probably keep it the same for 2.6.15.

I do have a bundle of Linux specific bug fixes to push,
but I didn't follow Tony's git branching strategy
correctly at first, so I've got to cherry pick a few...

-Len

Re: merge status

[Jeff Garzik]

Brown, Len wrote:
> I do have a bundle of Linux specific bug fixes to push,
> but I didn't follow Tony's git branching strategy
> correctly at first,

Is Tony's strategy described anywhere?

I'm curious how close it is to my own workflow.

	Jeff

Re: merge status

[Keith Owens]

On Thu, 10 Nov 2005 02:47:36 -0500, 
Jeff Garzik <jgarzik@pobox.com> wrote:
>Brown, Len wrote:
>> I do have a bundle of Linux specific bug fixes to push,
>> but I didn't follow Tony's git branching strategy
>> correctly at first,
>
>Is Tony's strategy described anywhere?

Tony's mail.

----------------------------------

Subject: change to the ia64 GIT trees
Date:	Tue, 16 Aug 2005 15:00:38 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: <linux-ia64@vger.kernel.org>
Cc: <akpm@osdl.org>

Now that GIT is smarter, and I'm more aware of what it can do
(and how to make it do it), I'm making a small change to how
I export GIT trees on kernel.org.

Instead of having separate trees for test and release, there
is now just one tree which contains "test" and "release" branches.
[or there will be soon when my deletion of the old test tree
is reflected on the kernel.org mirrors].

You can pull each of the branches separately with:

 $ git pull rsync://rsync.kernel.org/..../aegl/linux-2.6 test
or
 $ git pull rsync://rsync.kernel.org/..../aegl/linux-2.6 release

I wrote a "howto" for GIT about using branches as a Linux
subsystem maintainer that was included in the GIT sources
yesterday.  You can read a copy at http://tinyurl.com/d57dc

----------------------------------

RE: merge status

[Luck, Tony]

>>Is Tony's strategy described anywhere?
>
>Tony's mail.

There have been a couple of updates to the doc since
then to keep pace with changes in GIT.  The latest
is in the GIT sources in:

 Documentation/howto/using-topic-branches.txt

[or just click on http://tinyurl.com/bzll2]

It sounds like our approaches are very similar, just some
differences in terminology (you say "theme branch"
where I say "topic branch" etc.).  Plus perhaps some
variations in usage.  Almost all of my topic branches
only ever see one commit (or one series of commits if
the patch was supplied as a series of patches).  Plus
I haven't exported topic branches, mostly because I don't
often see people building on them[1].  But there are always
exceptions to any rule, so I did have a "swiotlb" branch
during this last pass to keep track of the move of
swiotlb.c out of arch/ia64/lib/ and into lib/.

So a review of the note I contributed to the GIT documents
would be helpful ... especially if you have any nifty
scripts that you use to manage things that you feel like
sharing.

-Tony

[1] But perhaps beacuse I don't what Linus to think I have
an oversize head: http://tinyurl.com/c3z53 :-)

RE: merge status

[Luck, Tony]

> -rw-r--r--    1 akpm     akpm        78245 Nov  9 11:19 git-ia64.patch

Some of this size may be a git artifact (or to be strictly accurate
an artifact of the way I maintain my git branches).  I just merged
up the latest linus branch into my test tree, and then ran:

 $ git diff linus test

which only came up with 34799 bytes of diff.  The extra bytes you
see may be due to some commits that went into my test tree, but
I goofed some of the comments ... so I ended up with the same patches
going to my release tree, but as different commits.  I assume that
quilt then figures out that this stuff is already in Linus tree?

I think that I may need to periodically ditch and re-create my test
branch ... it is full of "Auto-update from upstream" commits, plus
all the commits to pull in topic branches.  So when I've merged
over all the topic branches to send to Linus the contents of the
tree exactly match my release tree ... the history is very different
(and somewhat messy in places).

-Tony

Re: merge status

[Andrew Morton]

"Luck, Tony" <tony.luck@intel.com> wrote:
>
> > -rw-r--r--    1 akpm     akpm        78245 Nov  9 11:19 git-ia64.patch
> 
> Some of this size may be a git artifact (or to be strictly accurate
> an artifact of the way I maintain my git branches).  I just merged
> up the latest linus branch into my test tree, and then ran:
> 
>  $ git diff linus test
> 
> which only came up with 34799 bytes of diff.

Yes, sorry, I'd forgotten that I'm now including `git log' output in the
git-*.patch files.

diffstat patches/git-ia64.patch says:
 13 files changed, 364 insertions(+), 181 deletions(-)

>  The extra bytes you
> see may be due to some commits that went into my test tree, but
> I goofed some of the comments ... so I ended up with the same patches
> going to my release tree, but as different commits.  I assume that
> quilt then figures out that this stuff is already in Linus tree?
> 
> I think that I may need to periodically ditch and re-create my test
> branch ... it is full of "Auto-update from upstream" commits, plus
> all the commits to pull in topic branches.  So when I've merged
> over all the topic branches to send to Linus the contents of the
> tree exactly match my release tree ... the history is very different
> (and somewhat messy in places).

Yes, the `git log' output is >40k and is stuffed full of "Pull ...  into
...  branch" and "Auto-update from upstream" messages.  I wonder if there's
some way of asking git-diff to omit that stuff..

Re: merge status

[David Woodhouse]

On Wed, 2005-11-09 at 16:20 -0600, Steven French wrote:
> At the moment cifs does not have any infrastructure dependencies (unless
> you count minor changes to the cifs section of fs/Kconfig and a problem
> noticed trying to cancel d_notify requests), but I am trying to get a new
> upcall  in cifs (for callout to a helper utility to assist in kerberos
> authentication) coded in time - although it will be marked experimental.

Using the key management infrastructure? That has upcalls to obtain keys
already.

-- 
dwmw2

merge status

[Andrew Morton]

We're at day 12 of the two-week window, time for a quick peek at
outstanding patches in the subsystem trees.

-rw-r--r--    1 akpm     akpm       339882 Nov  9 11:19 git-scsi-misc.patch
-rw-r--r--    1 akpm     akpm       188863 Nov  9 11:29 git-acpi.patch
-rw-r--r--    1 akpm     akpm       151205 Nov  9 11:19 git-libata-all.patch
-rw-r--r--    1 akpm     akpm        78245 Nov  9 11:19 git-ia64.patch
-rw-r--r--    1 akpm     akpm        71651 Nov  9 11:19 git-ieee1394.patch
-rw-r--r--    1 akpm     akpm        71552 Nov  9 11:19 git-audit.patch
-rw-r--r--    1 akpm     akpm        47649 Nov  9 11:19 git-cryptodev.patch
-rw-r--r--    1 akpm     akpm        21829 Nov  9 11:19 git-blktrace.patch
-rw-r--r--    1 akpm     akpm        20989 Nov  9 11:19 git-infiniband.patch
-rw-r--r--    1 akpm     akpm         6687 Nov  9 11:19 git-agpgart.patch
-rw-r--r--    1 akpm     akpm         6569 Nov  9 11:19 git-cifs.patch
-rw-r--r--    1 akpm     akpm         2435 Nov  9 11:19 git-ntfs.patch
-rw-r--r--    1 akpm     akpm         1193 Nov  9 11:19 git-jfs.patch

The below are empty:

-rw-r--r--    1 akpm     akpm          131 Nov  9 11:19 git-block.patch
-rw-r--r--    1 akpm     akpm          124 Oct 23 11:38 git-watchdog.patch
-rw-r--r--    1 akpm     akpm          123 Nov  9 11:19 git-drm-via.patch
-rw-r--r--    1 akpm     akpm          122 Nov  9 11:19 git-scsi-rc-fixes.patch
-rw-r--r--    1 akpm     akpm          122 Nov  9 11:19 git-drm.patch
-rw-r--r--    1 akpm     akpm          118 Nov  9 11:19 git-alsa.patch
-rw-r--r--    1 akpm     akpm          115 Nov  9 11:19 git-sparc64.patch
-rw-r--r--    1 akpm     akpm          113 Nov  9 11:19 git-cpufreq.patch
-rw-r--r--    1 akpm     akpm          112 Nov  9 11:19 git-mtd.patch
-rw-r--r--    1 akpm     akpm          110 Nov  9 11:19 git-kbuild.patch
-rw-r--r--    1 akpm     akpm          110 Nov  9 11:19 git-input.patch
-rw-r--r--    1 akpm     akpm          102 Nov  9 11:19 git-nfs.patch
-rw-r--r--    1 akpm     akpm          102 Nov  9 11:19 git-drvmodel.patch
-rw-r--r--    1 akpm     akpm          101 Nov  9 11:19 git-arm-smp.patch
-rw-r--r--    1 akpm     akpm          100 Nov  9 11:19 git-serial.patch
-rw-r--r--    1 akpm     akpm           97 Nov  9 11:19 git-ucb.patch
-rw-r--r--    1 akpm     akpm           97 Nov  9 11:19 git-mmc.patch
-rw-r--r--    1 akpm     akpm           97 Nov  9 11:19 git-arm.patch
-rw-r--r--    1 akpm     akpm           87 Nov  9 11:19 git-xfs.patch

Most of this will be 2.6.16 material.  If not, promptness is urged.

Re: merge status

[James Bottomley]

On Wed, 2005-11-09 at 13:35 -0800, Andrew Morton wrote:
> -rw-r--r--    1 akpm     akpm       339882 Nov  9 11:19 git-scsi-misc.patch

This one is all 2.6.15 material.  I think I now (as of one minute ago)
have it updated to the last of the 2.6.15 (barring bug fix) patches.
I'd like to regression test it for a day or two, so I plan to request
the final merger on Friday.

James

Re: merge status

[Linus Torvalds]

On Wed, 9 Nov 2005, James Bottomley wrote:
>
> On Wed, 2005-11-09 at 13:35 -0800, Andrew Morton wrote:
> > -rw-r--r--    1 akpm     akpm       339882 Nov  9 11:19 git-scsi-misc.patch
> 
> This one is all 2.6.15 material.  I think I now (as of one minute ago)
> have it updated to the last of the 2.6.15 (barring bug fix) patches.
> I'd like to regression test it for a day or two, so I plan to request
> the final merger on Friday.

I'm hoping there aren't any infrastructure upheavals that break drivers 
again, because if there are, I think we're going to have to make a 
separate rule for things like that: they have to be merged early in the 
sequence or not at all.

And in _general_ I find it very wrong to consciously leave the merge until 
the last day of the merge window.

If that keeps happening, I think I'll just make sure that I don't always 
merge on the last day or two. Just to make sure that submaintainers don't 
"game" the system the wrong way. Maybe my "two weeks" are sometimes just 
ten days long, who knows..

			Linus

Re: merge status

[James Bottomley]

On Wed, 2005-11-09 at 14:01 -0800, Linus Torvalds wrote:
> 
> On Wed, 9 Nov 2005, James Bottomley wrote:
> >
> > On Wed, 2005-11-09 at 13:35 -0800, Andrew Morton wrote:
> > > -rw-r--r--    1 akpm     akpm       339882 Nov  9 11:19 git-scsi-misc.patch
> > 
> > This one is all 2.6.15 material.  I think I now (as of one minute ago)
> > have it updated to the last of the 2.6.15 (barring bug fix) patches.
> > I'd like to regression test it for a day or two, so I plan to request
> > the final merger on Friday.
> 
> I'm hoping there aren't any infrastructure upheavals that break drivers 
> again, because if there are, I think we're going to have to make a 
> separate rule for things like that: they have to be merged early in the 
> sequence or not at all.

There are one or two.  Part of the delay is getting sign offs from all
the people involved.

> And in _general_ I find it very wrong to consciously leave the merge until 
> the last day of the merge window.

Well ... I can give you the URL to pull now if you want ... I'd just
prefer to give this lot another day or so of testing.

> If that keeps happening, I think I'll just make sure that I don't always 
> merge on the last day or two. Just to make sure that submaintainers don't 
> "game" the system the wrong way. Maybe my "two weeks" are sometimes just 
> ten days long, who knows..

That's a nice theory, except that it's my contributors who drop me in it
by leaving their patch sets until you declare a kernel, dumping the
integration testing on me in whatever time window is left.

James

Re: merge status

[Linus Torvalds]

On Wed, 9 Nov 2005, James Bottomley wrote:
> 
> > If that keeps happening, I think I'll just make sure that I don't always 
> > merge on the last day or two. Just to make sure that submaintainers don't 
> > "game" the system the wrong way. Maybe my "two weeks" are sometimes just 
> > ten days long, who knows..
> 
> That's a nice theory, except that it's my contributors who drop me in it
> by leaving their patch sets until you declare a kernel, dumping the
> integration testing on me in whatever time window is left.

My point is that if that keeps on happening, then you miss the window, and 
are hopefully ready EARLY next time around, four weeks later, when the 
next window opens.

And if your submaintainers keep screwing _you_, then you tell them to stop 
it, and stop accepting their patches in that window, so that it's _their_ 
code that gets delayed, not yours.

The development SHOULD NOT happen during the merge window. The development 
should have happened in the tree you wait to merge /while waiting/ for the 
window to open.

If you're doing the development during the merge window, not only do you 
get in late in the window, you also do a hurried job and thus almost 
certainly have a worse process.

The whole point of having timely merge windows is that we _can_ just say 
"sorry, you missed the bus, wait for the next one".

And trust me, I _will_ say that. People always complain that I'm being too 
soft. Not so this time. If people miss the merge window or start abusing 
it with hurried last-minute things that just cause problems for -rc1, I'll 
just refuse to merge, and laugh in their faces derisively when they whine 
plaintively at me, and tell them there's going to be a new opening soon 
enough.

If two weeks of merge window is too short, maybe the four weeks _between_ 
the windows is long enough to sort things out.

		Linus

Re: merge status

[Jeff Garzik]

Linus Torvalds wrote:
> The development SHOULD NOT happen during the merge window. The development 
> should have happened in the tree you wait to merge /while waiting/ for the 
> window to open.

In theory.  In reality, when the drain unclogs, peoples' output increases.

I'm NOT arguing either side, mind you.  Just making a note.


> If two weeks of merge window is too short, maybe the four weeks _between_ 
> the windows is long enough to sort things out.

Honestly, I wonder if two weeks is too long.  The shorter the window, 
the more people will work the way you describe above.

	Jeff

Re: merge status

[Andrew Morton]

James Bottomley <James.Bottomley@SteelEye.com> wrote:
>
> it's my contributors who drop me in it
> by leaving their patch sets until you declare a kernel, dumping the
> integration testing on me in whatever time window is left.

Yes, I think I'm noticing an uptick in patches as soon as a kernel is
released.

It's a bit irritating, and is unexpected (here, at least).  I guess people
like to hold onto their work for as long as possible so when they release
it, it's in the best possible shape.

I guess all we can do is to encourage people to merge up when it's working,
not when it's time to merge it into mainline.

One could just say "if I don't have it by the time 2.6.n is released, it
goes into 2.6.n+2", but that's probably getting outside the realm of
practicality.

Re: merge status

[Jesper Juhl]

On 11/10/05, Andrew Morton <akpm@osdl.org> wrote:
> James Bottomley <James.Bottomley@SteelEye.com> wrote:
> >
> > it's my contributors who drop me in it
> > by leaving their patch sets until you declare a kernel, dumping the
> > integration testing on me in whatever time window is left.
>
> Yes, I think I'm noticing an uptick in patches as soon as a kernel is
> released.
>
> It's a bit irritating, and is unexpected (here, at least).  I guess people
> like to hold onto their work for as long as possible so when they release
> it, it's in the best possible shape.
>
> I guess all we can do is to encourage people to merge up when it's working,
> not when it's time to merge it into mainline.
>
> One could just say "if I don't have it by the time 2.6.n is released, it
> goes into 2.6.n+2", but that's probably getting outside the realm of
> practicality.

I personally find that a nice flow is to just continuously push
patches to you to merge into -mm, then once the merge window opens you
usually push the stuff onto Linus and it'll make the next kernel.
Anything I submit after the merge window opens will just stay in -mm
and wait for the next merge window (or next+1 depending on the patch).

But then my stuff is usually quite simple, so I guess that doesn't
work for everyone, but for me at least it seems to work well.


--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: merge status

[Linus Torvalds]

On Wed, 9 Nov 2005, Andrew Morton wrote:
> 
> One could just say "if I don't have it by the time 2.6.n is released, it
> goes into 2.6.n+2", but that's probably getting outside the realm of
> practicality.

I think it would be a good thing to _aim_ for, and just to keep things 
practical just not make it too much of a hard rule.

I think one reason -mm has worked so damn well (apart from you being "The 
Calmest Man on Earth"(tm)) is because it's essentially been that buffer 
for anything non-trivial. Sometimes the "n+2" has been a lot more than 
"n+2" in fact, and that's often good.

(And at the same time, -mm has enough visibility that it doesn't drive 
developers crazy even when the "n+2" ends up being "n+5" or somethiing).

I'd _hope_ that the same kind of situation could work for some of the 
majos subsystem git trees too: where the maintainer tree is well enough 
known that it gets sufficient coverage for that area that a "+2" approach 
for merging into the default kernel is practical.

I also think it certainly _should_ be possible for the big areas that have
well-defined target audiences. Especially since git should hopefulyl be 
very good at allowing such a target audience to actually track (and merge) 
such trees on their own.

Ie it should be perfectly possible (and easy) to track both my tree and 
some other tree (sound, scsi, network device development) in two branches, 
and the person doing that tracking should have basically trivial merging.

So we do have the technology. Whether we can make it work in practice, 
that's another issue ;)

			Linus

Re: merge status

[Pavel Machek]

Hi!

> Ie it should be perfectly possible (and easy) to track both my tree and 
> some other tree (sound, scsi, network device development) in two branches, 
> and the person doing that tracking should have basically trivial merging.

Unfortunately, I do not know how to track -mm this way. I do not think
tracking both linus and -mm tree using git is possible.


								Pavel
-- 
Thanks, Sharp!

Re: merge status

[Con Kolivas]

On Thu, 10 Nov 2005 10:01 am, Andrew Morton wrote:
> James Bottomley <James.Bottomley@SteelEye.com> wrote:
> > it's my contributors who drop me in it
> > by leaving their patch sets until you declare a kernel, dumping the
> > integration testing on me in whatever time window is left.
>
> Yes, I think I'm noticing an uptick in patches as soon as a kernel is
> released.
>
> It's a bit irritating, and is unexpected (here, at least).  I guess people
> like to hold onto their work for as long as possible so when they release
> it, it's in the best possible shape.

I suspect part of that is the concern about whether the code will merge with 
whatever -mm looks like next. Of course you already do ludicrous amounts of 
merging, but sometimes you'll just throw it back and say "too many rejects".

Cheers,
Con

Re: merge status

[Andrew Morton]

Con Kolivas <kernel@kolivas.org> wrote:
>
> On Thu, 10 Nov 2005 10:01 am, Andrew Morton wrote:
> > James Bottomley <James.Bottomley@SteelEye.com> wrote:
> > > it's my contributors who drop me in it
> > > by leaving their patch sets until you declare a kernel, dumping the
> > > integration testing on me in whatever time window is left.
> >
> > Yes, I think I'm noticing an uptick in patches as soon as a kernel is
> > released.
> >
> > It's a bit irritating, and is unexpected (here, at least).  I guess people
> > like to hold onto their work for as long as possible so when they release
> > it, it's in the best possible shape.
> 
> I suspect part of that is the concern about whether the code will merge with 
> whatever -mm looks like next. Of course you already do ludicrous amounts of 
> merging, but sometimes you'll just throw it back and say "too many rejects".

Well of course that's not a concern for people who work against the git
trees - scsi/usb/ia64/whatever developers.

But yes, sometimes people's work does clash just too much with things which
are already in subsystem trees or in -mm.  Fortunately it's relatively
rare, and I do think it's best to ask people to develop against latest
-linus rather than against a crazy -mmoving target.

Especially as lots of people are stuck using git, rather than high-tech
patch management technologies ;)


Actually, I disagree with you - it's at 2.6.x release-time that all trees,
including -mm are at their most divergent.  Presumably these developers are
working against the relevant subsystem git tree, and hence can merge into
the subsystem maintainer at any time.

Re: merge status

[James Bottomley]

On Wed, 2005-11-09 at 15:01 -0800, Andrew Morton wrote:
> James Bottomley <James.Bottomley@SteelEye.com> wrote:
> >
> > it's my contributors who drop me in it
> > by leaving their patch sets until you declare a kernel, dumping the
> > integration testing on me in whatever time window is left.
> 
> Yes, I think I'm noticing an uptick in patches as soon as a kernel is
> released.
> 
> It's a bit irritating, and is unexpected (here, at least).  I guess people
> like to hold onto their work for as long as possible so when they release
> it, it's in the best possible shape.

Well ... I can guess how it goes:

Manager:   "2.6.x is out, are our patches in it"
Developer: .oO(crap I forgot about this, better get my skates on)
           "No, but they will be in the next kernel"
            .oO(As long as I get them in the current merge window)

> I guess all we can do is to encourage people to merge up when it's working,
> not when it's time to merge it into mainline.

OK ... I'd really like that, but I think in order to do that I think we
have to have a tree that represents only everything that's going
upstream.  That would be a -mm but without the patches that aren't going
to be included in the next release.  I suppose we could do this today
simply by making it the sum of all the git trees and nothing else.  The
closer this tree is to what mainline will be next release, the easier it
will be to encourage people to test it.

> One could just say "if I don't have it by the time 2.6.n is released, it
> goes into 2.6.n+2", but that's probably getting outside the realm of
> practicality.

We could always try it.  Practically the way to do this is to reduce the
merge window down to a single day, but to do that you obviously have to
give us prior notice of a 2.6.<x> release, which might be the
impractical bit ...

James

Re: merge status

[Jens Axboe]

On Wed, Nov 09 2005, Andrew Morton wrote:
> James Bottomley <James.Bottomley@SteelEye.com> wrote:
> >
> > it's my contributors who drop me in it
> > by leaving their patch sets until you declare a kernel, dumping the
> > integration testing on me in whatever time window is left.
> 
> Yes, I think I'm noticing an uptick in patches as soon as a kernel is
> released.
> 
> It's a bit irritating, and is unexpected (here, at least).  I guess people
> like to hold onto their work for as long as possible so when they release
> it, it's in the best possible shape.

Sometimes I do hold on to stuff for a little while because I don't think
it's quite ready yet, but that's not because I don't want it out there.
It's more of a "I don't feel like spending 1-2 hours making and testing
a -mm version", really. And if I just send you the vanilla patch for
something I know you have to massage to get to apply, a cloud of guilt
builds up over my head. With so many patches in -mm, I don't want to put
that extra strain on you.

-- 
Jens Axboe

Re: merge status

[Andrew Morton]

Jens Axboe <axboe@suse.de> wrote:
>
>  It's more of a "I don't feel like spending 1-2 hours making and testing
>  a -mm version"

There shouldn't be a need for special -m version of patches.  Very usually
the diff-against-linus can be made to work quite easily.  Sufficiently
easily that I resync with all the git trees a couple of times a day.

Re: merge status

[Jens Axboe]

On Thu, Nov 10 2005, Andrew Morton wrote:
> Jens Axboe <axboe@suse.de> wrote:
> >
> >  It's more of a "I don't feel like spending 1-2 hours making and testing
> >  a -mm version"
> 
> There shouldn't be a need for special -m version of patches.  Very usually
> the diff-against-linus can be made to work quite easily.  Sufficiently
> easily that I resync with all the git trees a couple of times a day.

Often the patch itself may not take too much work, but you still need to
set up a -mm test directory, compile, boot, and test the stuff.

-- 
Jens Axboe

Re: merge status

[Andrew Morton]

Jens Axboe <axboe@suse.de> wrote:
>
> On Thu, Nov 10 2005, Andrew Morton wrote:
> > Jens Axboe <axboe@suse.de> wrote:
> > >
> > >  It's more of a "I don't feel like spending 1-2 hours making and testing
> > >  a -mm version"
> > 
> > There shouldn't be a need for special -m version of patches.  Very usually
> > the diff-against-linus can be made to work quite easily.  Sufficiently
> > easily that I resync with all the git trees a couple of times a day.
> 
> Often the patch itself may not take too much work, but you still need to
> set up a -mm test directory, compile, boot, and test the stuff.

Most of the other git-tree maintainers don't bother with any of that. 
acpi, agp, alsa, arm, ...  xfs.  The trees which have special -mm branches
are just drm, ieee1394, jfs, mips and netdev.

Where it all comes unstuck at present is if a maintainer has multiple
branches, and some of those branches contains diffs which are in other
branches.  If that happens, the diffs I generate throw huge rejects. 
But even then, if one branch is a strict superset of another, I can just
pull the superset one.

Re: merge status

[Dave Kleikamp]

On Thu, 2005-11-10 at 01:30 -0800, Andrew Morton wrote:
> Jens Axboe <axboe@suse.de> wrote:
> >
> > On Thu, Nov 10 2005, Andrew Morton wrote:
> > > Jens Axboe <axboe@suse.de> wrote:
> > > >
> > > >  It's more of a "I don't feel like spending 1-2 hours making and testing
> > > >  a -mm version"
> > > 
> > > There shouldn't be a need for special -m version of patches.  Very usually
> > > the diff-against-linus can be made to work quite easily.  Sufficiently
> > > easily that I resync with all the git trees a couple of times a day.
> > 
> > Often the patch itself may not take too much work, but you still need to
> > set up a -mm test directory, compile, boot, and test the stuff.
> 
> Most of the other git-tree maintainers don't bother with any of that. 
> acpi, agp, alsa, arm, ...  xfs.  The trees which have special -mm branches
> are just drm, ieee1394, jfs, mips and netdev.

jfs doesn't really maintain a separate -mm branch.  I set up the tree to
be flexible if I ever had a reason to hold something back from the Linus
tree, but in reality, -mm is equal to HEAD, and the -linus branch is
usually the same when I ask for it to be pulled.

-- 
David Kleikamp
IBM Linux Technology Center

Re: merge status

[Pavel Machek]

Hi!

> > it's my contributors who drop me in it
> > by leaving their patch sets until you declare a kernel, dumping the
> > integration testing on me in whatever time window is left.
> 
> Yes, I think I'm noticing an uptick in patches as soon as a kernel is
> released.
> 
> It's a bit irritating, and is unexpected (here, at least).  I guess people
> like to hold onto their work for as long as possible so when they release
> it, it's in the best possible shape.
> 
> I guess all we can do is to encourage people to merge up when it's working,
> not when it's time to merge it into mainline.

Well, merge when previous stuff is way easier, because you can just do
cg-diff. When my previous changes enter mainline, it is suddenly very
easy to generate next patch. [And it makes sense, it is

cg-diff -r origin:

"let's see what I missed].

								Pavel
-- 
Thanks, Sharp!

Re: merge status

[Bill Davidsen]

Andrew Morton wrote:
> James Bottomley <James.Bottomley@SteelEye.com> wrote:
> 
>>it's my contributors who drop me in it
>>by leaving their patch sets until you declare a kernel, dumping the
>>integration testing on me in whatever time window is left.
> 
> 
> Yes, I think I'm noticing an uptick in patches as soon as a kernel is
> released.
> 
> It's a bit irritating, and is unexpected (here, at least).  I guess people
> like to hold onto their work for as long as possible so when they release
> it, it's in the best possible shape.
> 
> I guess all we can do is to encourage people to merge up when it's working,
> not when it's time to merge it into mainline.
> 
> One could just say "if I don't have it by the time 2.6.n is released, it
> goes into 2.6.n+2", but that's probably getting outside the realm of
> practicality.

Consider that people want to send you something which will work with the 
new kernel and are holding back until they can send you something which 
has a higher chance of working as delivered. If you want to avoid having 
a rediff be part of the integration testing I thought you were trying to 
avoid.

I interpreted that as people trying to make stuff easier for you.


-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: merge status

[Roland Dreier]

    > -rw-r--r--    1 akpm     akpm        20989 Nov  9 11:19 git-infiniband.patch

Most of this is for 2.6.15.  I will post a git pull request later
today or tomorrow morning.

 - R.

Re: merge status

[Jody McIntyre]

On Wed, Nov 09, 2005 at 01:35:58PM -0800, Andrew Morton wrote:
> 
> We're at day 12 of the two-week window, time for a quick peek at
> outstanding patches in the subsystem trees.
> 
> -rw-r--r--    1 akpm     akpm        71651 Nov  9 11:19 git-ieee1394.patch

I thought the two-week window was only for new stuff, not
bugfixes/cleanup.  Did I misread something?  If so, oh well, these
changes will have to wait for 2.6.16.  I don't feel comfortable sending
up something that's only been in -mm for 2 days.

Cheers,
Jody

Re: merge status

[Linus Torvalds]

On Wed, 9 Nov 2005, Jody McIntyre wrote:

> On Wed, Nov 09, 2005 at 01:35:58PM -0800, Andrew Morton wrote:
> > 
> > -rw-r--r--    1 akpm     akpm        71651 Nov  9 11:19 git-ieee1394.patch
> 
> I thought the two-week window was only for new stuff, not
> bugfixes/cleanup

If you have a 71kB patch, it definitely counts as new stuff and not just 
trivial bugfixes.

		Linus

Re: merge status

[Jody McIntyre]

On Wed, Nov 09, 2005 at 02:18:32PM -0800, Linus Torvalds wrote:

> If you have a 71kB patch, it definitely counts as new stuff and not just 
> trivial bugfixes.

Fair enough.

Can I still send a 2k spinlock fix in ~2 weeks?  That's the only thing I
really want to get in to 2.6.15.

Jody

> 
> 		Linus

Re: merge status

[Andrew Morton]

Jody McIntyre <scjody@modernduck.com> wrote:
>
> Can I still send a 2k spinlock fix in ~2 weeks?

Bugfixes are of course always welcome - that's the entire reason for having
the stabilisation period.

>  That's the only thing I
> really want to get in to 2.6.15.

I think it's fair to make exemptions for subsystems which have been
neglected, or are flakey, or which are newly-merged, or which have a new
batch of maintainers who are struggling to get things back into shape and
back into sync with offstream trees.  Because a) those subsystems are
usually already pretty buggy and b) the team needs extra help to get stuff
back into shape asap.

I'd view 1394 as only partly-emerged from that state ;)

As long as you understand the overall philosophy of what we're trying to
do, you should be able to make your own decisions about what's suitable,
and when.

Re: merge status

[Linus Torvalds]

On Wed, 9 Nov 2005, Jody McIntyre wrote:
>
> On Wed, Nov 09, 2005 at 02:18:32PM -0800, Linus Torvalds wrote:
> 
> > If you have a 71kB patch, it definitely counts as new stuff and not just 
> > trivial bugfixes.
> 
> Fair enough.
> 
> Can I still send a 2k spinlock fix in ~2 weeks?  That's the only thing I
> really want to get in to 2.6.15.

Sure, there's nothing wrong with keeping "ongoing development" around, and 
then just asking me to pull the unrelated fixes. 

Either using separate patches to synchronize the bugfixes, or just using 
separate git branches for development and merging up to me. As usual, Jeff 
ends up the poster-boy for git branches (these days there are certainly 
others that do it too, but Jeff has done it more and for longer than 
most).

For example, going to Jeff's networking tree:

	http://www.kernel.org/git/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=summary

you can see

	15 hours ago 	ALL 		shortlog | log
	15 hours ago 	e100-sbit 	shortlog | log
	16 hours ago 	upstream-linus 	shortlog | log
	16 hours ago 	upstream 	shortlog | log
	20 hours ago 	master 		shortlog | log
	4 days ago 	sky2 		shortlog | log
	4 days ago 	sis900-wol 	shortlog | log
	4 days ago 	8139-thread 	shortlog | log

where "upstream-linus" is the part I merged today, while he has possibly 
other development work in the other branches.

			Linus

Re: merge status

[Anton Altaparmakov]

On Wed, 9 Nov 2005, Andrew Morton wrote:

> 
> We're at day 12 of the two-week window, time for a quick peek at
> outstanding patches in the subsystem trees.
> 
> -rw-r--r--    1 akpm     akpm       339882 Nov  9 11:19 git-scsi-misc.patch
> -rw-r--r--    1 akpm     akpm       188863 Nov  9 11:29 git-acpi.patch
> -rw-r--r--    1 akpm     akpm       151205 Nov  9 11:19 git-libata-all.patch
> -rw-r--r--    1 akpm     akpm        78245 Nov  9 11:19 git-ia64.patch
> -rw-r--r--    1 akpm     akpm        71651 Nov  9 11:19 git-ieee1394.patch
> -rw-r--r--    1 akpm     akpm        71552 Nov  9 11:19 git-audit.patch
> -rw-r--r--    1 akpm     akpm        47649 Nov  9 11:19 git-cryptodev.patch
> -rw-r--r--    1 akpm     akpm        21829 Nov  9 11:19 git-blktrace.patch
> -rw-r--r--    1 akpm     akpm        20989 Nov  9 11:19 git-infiniband.patch
> -rw-r--r--    1 akpm     akpm         6687 Nov  9 11:19 git-agpgart.patch
> -rw-r--r--    1 akpm     akpm         6569 Nov  9 11:19 git-cifs.patch

> -rw-r--r--    1 akpm     akpm         2435 Nov  9 11:19 git-ntfs.patch

Odd.  "git format-patch -n `cat 
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/HEAD`" returns nothing so 
I can only assume that it is empty, too.  No idea why the size is 2.4k...  
Certainly I do not remember committing anything since I last pushed to 
Linus...

> -rw-r--r--    1 akpm     akpm         1193 Nov  9 11:19 git-jfs.patch
> 
> The below are empty:
> 
> -rw-r--r--    1 akpm     akpm          131 Nov  9 11:19 git-block.patch
> -rw-r--r--    1 akpm     akpm          124 Oct 23 11:38 git-watchdog.patch
> -rw-r--r--    1 akpm     akpm          123 Nov  9 11:19 git-drm-via.patch
> -rw-r--r--    1 akpm     akpm          122 Nov  9 11:19 git-scsi-rc-fixes.patch
> -rw-r--r--    1 akpm     akpm          122 Nov  9 11:19 git-drm.patch
> -rw-r--r--    1 akpm     akpm          118 Nov  9 11:19 git-alsa.patch
> -rw-r--r--    1 akpm     akpm          115 Nov  9 11:19 git-sparc64.patch
> -rw-r--r--    1 akpm     akpm          113 Nov  9 11:19 git-cpufreq.patch
> -rw-r--r--    1 akpm     akpm          112 Nov  9 11:19 git-mtd.patch
> -rw-r--r--    1 akpm     akpm          110 Nov  9 11:19 git-kbuild.patch
> -rw-r--r--    1 akpm     akpm          110 Nov  9 11:19 git-input.patch
> -rw-r--r--    1 akpm     akpm          102 Nov  9 11:19 git-nfs.patch
> -rw-r--r--    1 akpm     akpm          102 Nov  9 11:19 git-drvmodel.patch
> -rw-r--r--    1 akpm     akpm          101 Nov  9 11:19 git-arm-smp.patch
> -rw-r--r--    1 akpm     akpm          100 Nov  9 11:19 git-serial.patch
> -rw-r--r--    1 akpm     akpm           97 Nov  9 11:19 git-ucb.patch
> -rw-r--r--    1 akpm     akpm           97 Nov  9 11:19 git-mmc.patch
> -rw-r--r--    1 akpm     akpm           97 Nov  9 11:19 git-arm.patch
> -rw-r--r--    1 akpm     akpm           87 Nov  9 11:19 git-xfs.patch
> 
> Most of this will be 2.6.16 material.  If not, promptness is urged.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: merge status

[Andrew Morton]

Anton Altaparmakov <aia21@cam.ac.uk> wrote:
>
> > -rw-r--r--    1 akpm     akpm         2435 Nov  9 11:19 git-ntfs.patch
> 
> Odd.  "git format-patch -n `cat 
> /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/HEAD`" returns nothing so 
> I can only assume that it is empty, too.  No idea why the size is 2.4k...  
> Certainly I do not remember committing anything since I last pushed to 
> Linus...

Ah, sorry, that appears to be all changelog noise coming out of
`git log origin..git-ntfs'

GIT e3b48297a3d9a852887f76e82fa7de5348ac1d9e master.kernel.org:/pub/scm/linux/kernel/git/aia21/ntfs-2.6-devel.git

commit e3b48297a3d9a852887f76e82fa7de5348ac1d9e
Merge: 33eaa30ec348a6a1391f556dd6eeb3d27054df95 94b166a7cbc232df279e1f7d5a8acfb6b8d02d59
Author: Anton Altaparmakov <aia21@hera.kernel.org>
Date:   Tue Nov 1 07:58:27 2005 -0800

    Merge branch 'master' of /home/aia21/ntfs-2.6

commit 33eaa30ec348a6a1391f556dd6eeb3d27054df95
Merge: b05576b308efcd07a295a89b2b1a08fae0811ce0 1f04c0a24b2f3cfe89c802a24396263623e3512d
Author: Anton Altaparmakov <aia21@hera.kernel.org>
Date:   Mon Oct 31 02:39:42 2005 -0800

    Merge branch 'master' of /home/aia21/ntfs-2.6



etcetera.  

Re: merge status

[Linus Torvalds]

On Wed, 9 Nov 2005, Andrew Morton wrote:
> 
> Ah, sorry, that appears to be all changelog noise coming out of
> `git log origin..git-ntfs'

You can use the "--no-merges" flag to git log to tell it to ignore merges.

(Of course, sometimes the merges themselves are interesting, so it's a 
matter of taste. In the specific case of the -mm logic, I suspect the 
merges aren't of interest and you're probably better off ignoring them).

			Linus

Re: merge status

[Russell King]

On Wed, Nov 09, 2005 at 01:35:58PM -0800, Andrew Morton wrote:
> We're at day 12 of the two-week window, time for a quick peek at
> outstanding patches in the subsystem trees.

And I've just committed that patch set to convert platform drivers
to struct platform_driver... which is about 250K.

Anything not converted continues to work as it always used to, so
the only breakage is if I mis-converted something.  However, I've
build-tested allyesconfig on i386, and several ARM configs, and I'm
not aware of any build problems.

This couldn't be submitted earlier because ARM SMP work took
priority, and getting to a stage where the platform_driver stuff
was suitable against the rapidly moving target is rather, err,
time consuming.  Plus, gregkh only recently gave his ack to it.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: merge status

[Jeff Garzik]

Andrew Morton wrote:
> We're at day 12 of the two-week window, time for a quick peek at
> outstanding patches in the subsystem trees.
> 
> -rw-r--r--    1 akpm     akpm       151205 Nov  9 11:19 git-libata-all.patch

For my stuff, libata and netdev, the 2.6.15 code has been upstream for a 
while.

Whatever holdovers there are are definitely waiting for 2.6.16 (and 
beyond, for stuff like Alan's libata PATA drivers).

	Jeff

Re: merge status

[Jens Axboe]

On Wed, Nov 09 2005, Andrew Morton wrote:
> -rw-r--r--    1 akpm     akpm        21829 Nov  9 11:19 git-blktrace.patch

This one can wait for the next release, so if it's ok with you I'll just
let it simmer in -mm some more. I do make sure that the blktrace branch
of the git tree is uptodate so the amount of hassle should be low for
you.

-- 
Jens Axboe