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.
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
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
> -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.
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/
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
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
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
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
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
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
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
Jody McIntyre <[email protected]> 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.
Anton Altaparmakov <[email protected]> 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 <[email protected]>
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 <[email protected]>
Date: Mon Oct 31 02:39:42 2005 -0800
Merge branch 'master' of /home/aia21/ntfs-2.6
etcetera.
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
> -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
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
James Bottomley <[email protected]> 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.
On 11/10/05, Andrew Morton <[email protected]> wrote:
> James Bottomley <[email protected]> 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 <[email protected]>
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
"Luck, Tony" <[email protected]> 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..
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
On Thu, 10 Nov 2005 10:01 am, Andrew Morton wrote:
> James Bottomley <[email protected]> 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
On Wed, 2005-11-09 at 15:01 -0800, Andrew Morton wrote:
> James Bottomley <[email protected]> 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
Con Kolivas <[email protected]> wrote:
>
> On Thu, 10 Nov 2005 10:01 am, Andrew Morton wrote:
> > James Bottomley <[email protected]> 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.
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
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
>-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
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
On Thu, 10 Nov 2005 02:47:36 -0500,
Jeff Garzik <[email protected]> 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" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
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
----------------------------------
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
On Wed, Nov 09 2005, Andrew Morton wrote:
> James Bottomley <[email protected]> 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
Jens Axboe <[email protected]> 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.
On Thu, Nov 10 2005, Andrew Morton wrote:
> Jens Axboe <[email protected]> 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
Jens Axboe <[email protected]> wrote:
>
> On Thu, Nov 10 2005, Andrew Morton wrote:
> > Jens Axboe <[email protected]> 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.
Andrew Morton wrote:
> 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.
[related tangent, in case this is useful to others]
It's not quite correct to say that I have a special -mm branch. In my
two primary work areas, libata-dev.git and netdev-2.6.git, I have a
bunch of branches, which fall into three categories:
'master': vanilla upstream Linus tree
themes: various patch queues, each for a single purpose.
standard patch queues include...
upstream: stuff queued for upstream
upstream-fixes: stuff queued for -rc
8139-thread: example non-upstream dev branch
ncq: another non-upstream dev branch
'ALL': a superset merge of all theme branches which
are considered OK for testing by brave users.
The 'ALL' superset branch is not only what you (Andrew) pull into -mm,
its also the basis for -libataN and -netdevN patches, and in general the
best way for users to slurp "all the useful bits."
Using theme branches and a superset branch allows for maximum parallel
development -- even applying conflicting patches -- and then using git
to merge them together. The separated-out branches also allow for
fine-grained selection of the material to push upstream, i.e. no false
dependencies, easier cherrypicking.
I've actually worked this way since the early BitKeeper days; BK didn't
make it easy for me to export the tons of local theme branches I
manipulated, just the superset branch. Since git makes it easy, you
finally get the full picture of libata/netdev development, and the best
of both worlds: both a superset branch (easy testing) and theme
branches (parallel development).
Jeff
On Thu, 2005-11-10 at 01:30 -0800, Andrew Morton wrote:
> Jens Axboe <[email protected]> wrote:
> >
> > On Thu, Nov 10 2005, Andrew Morton wrote:
> > > Jens Axboe <[email protected]> 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
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!
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!
>>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 :-)
Andrew Morton wrote:
> James Bottomley <[email protected]> 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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me