merge status

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!

[uml-devel] Re: merge status

[Rob Landley]

Linus said this:

> 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.

And so I thought a bit about what that tree would be for UML (-mm?  -bb?) and 
decided "it's gotta be Jeff's tree as defined by 
user-mode-linux.sf.net/patches.html", so I grabbed the big rolled up tarball 
there that applies on top of 2.6.15-rc1:
http://user-mode-linux.sourceforge.net/work/current/2.6/2.6.15-rc1/patches.tar

And applied them all (in series order) with a for loop.

I used the following mini-config (using the new mechanism where if you put a 
mini-config in the file "allno.config" and run "make ARCH=um allnoconfig", 
you get a config with just this switched on, plus any required dependencies.  
Neat, eh?)

CONFIG_MODE_SKAS=y
CONFIG_BINFMT_ELF=y
CONFIG_HOSTFS=y
CONFIG_SYSCTL=y
CONFIG_STDERR_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_UBD=y
CONFIG_TMPFS=y
CONFIG_SWAP=y
CONFIG_LBD=y
CONFIG_EXT2_FS=y
CONFIG_PROC_FS=y

The build broke on the first file it tried to compile:

  CHK     include/linux/version.h
gcc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing 
-fno-common -ffreestanding -O2     -fomit-frame-pointer  -D__arch_um__ 
-DSUBARCH=\"i386\" -Iarch/um/include  
-I/home/landley/newbuild/firmware-build/sources/packages/linux-2.6.14/arch/um/include/skas 
-Dvmap=kernel_vmap -Din6addr_loopback=kernel_in6addr_loopback 
-Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask  -U__i386__ -Ui386 
-march=i686 -mpreferred-stack-boundary=2 -D_LARGEFILE64_SOURCE    -nostdinc 
-isystem /usr/lib/gcc-lib/i486-linux/3.3.5/include -D__KERNEL__ -Iinclude  
-include include/linux/autoconf.h -S -o arch/um/kernel-offsets.s 
arch/um/sys-i386/kernel-offsets.c
In file included from include/asm/thread_info.h:12,
                 from include/linux/thread_info.h:21,
                 from include/linux/spinlock.h:53,
                 from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/um/sys-i386/kernel-offsets.c:3:
include/asm/processor.h:19: error: field `tls' has incomplete type
In file included from arch/um/include/um_mmu.h:17,
                 from include/asm/mmu.h:9,
                 from include/linux/sched.h:23,
                 from arch/um/sys-i386/kernel-offsets.c:3:
/home/landley/newbuild/firmware-build/sources/packages/linux-2.6.14/arch/um/include/skas/mmu-skas.h:19: 
error: syntax error before "uml_ldt_t"
/home/landley/newbuild/firmware-build/sources/packages/linux-2.6.14/arch/um/include/skas/mmu-skas.h:19: 
warning: no semicolon at end of struct or union
In file included from include/asm/mmu.h:9,
                 from include/linux/sched.h:23,
                 from arch/um/sys-i386/kernel-offsets.c:3:
arch/um/include/um_mmu.h:25: error: field `skas' has incomplete type
make: *** [arch/um/kernel-offsets.s] Error 1

So I re-extracted 2.6.15-rc1, modified the for loop to apply them one at a 
time and build between each one, and ran that.

The build broke in a different way, after the very first patch 
(fix-stub-syscall6):

  CHK     usr/initramfs_list
  CC      arch/um/kernel/skas/clone.o
arch/um/kernel/skas/clone.c: In function `stub_clone_handler':
arch/um/kernel/skas/clone.c:35: error: aggregate value used where an integer 
was expected
make[2]: *** [arch/um/kernel/skas/clone.o] Error 1
make[1]: *** [arch/um/kernel/skas] Error 2
make: *** [arch/um/kernel] Error 2

So my question is: has anybody actually tried this patch series, and if so, 
_how_?  Am I doing something wrong?  (Building on ubuntu Horny Hedgehog with 
gcc 3.3.5)

Rob


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Blaisorblade]

On Wednesday 16 November 2005 14:36, Rob Landley wrote:
> Linus said this:
> > 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.
>
> And so I thought a bit about what that tree would be for UML (-mm?  -bb?)
> and decided "it's gotta be Jeff's tree as defined by
> user-mode-linux.sf.net/patches.html", so I grabbed the big rolled up
> tarball there that applies on top of 2.6.15-rc1:
> http://user-mode-linux.sourceforge.net/work/current/2.6/2.6.15-rc1/patches.
>tar

Definitely Jeff's tree is a first filter for his work, but I've not seen it 
working a lot as a collector, especially for little fixes - but there it 
makes sense.

I tend to send directly to Andrew and he forwards them to Linus (in many cases 
so fast that I wonder if they appear in one -mm release), but I currently do 
not have a public tree.

> And applied them all (in series order) with a for loop.

Can I suggest using quilt for this (as it's more powerful and easy to use)?

Especially when you add other patches as compile fixups...

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Rob Landley]

On Friday 18 November 2005 01:08, Blaisorblade wrote:
> On Wednesday 16 November 2005 14:36, Rob Landley wrote:
> > Linus said this:
> > > 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.
> >
> > And so I thought a bit about what that tree would be for UML (-mm?  -bb?)
> > and decided "it's gotta be Jeff's tree as defined by
> > user-mode-linux.sf.net/patches.html", so I grabbed the big rolled up
> > tarball there that applies on top of 2.6.15-rc1:
> > http://user-mode-linux.sourceforge.net/work/current/2.6/2.6.15-rc1/patche
> >s. tar
>
> Definitely Jeff's tree is a first filter for his work, but I've not seen it
> working a lot as a collector, especially for little fixes - but there it
> makes sense.
>
> I tend to send directly to Andrew and he forwards them to Linus (in many
> cases so fast that I wonder if they appear in one -mm release), but I
> currently do not have a public tree.

So there currently _is_ no one UML tree that people interested in the most 
recent UML developments can check out.  We basically have to wait until it 
hits mainline.

That's sad.  I think I'll stick with Jeff's tree as the closest I've come so 
far...

> > And applied them all (in series order) with a for loop.
>
> Can I suggest using quilt for this (as it's more powerful and easy to use)?
>
> Especially when you add other patches as compile fixups...

I'm not applying the other patches at the moment.  Right now I'm just trying 
to get Jeff's tree to build for me.  If I have time tonight I'm going to 
cherry-pick his patch list to see which ones I can get to compile, and give 
him the list of each one that breaks my build (and how).  I just mentioned 
that #2 of the recent 4 sent to Andrew broke the build for me, but that's not 
the only breakage I see from Jeff's tree.  (I currently have access to four 
different build environments.  I was focusing on the PLD x86-64 system I'm 
borrowing, but right now I'm focusing on my ubuntu laptop.  Then knoppix, and 
then my Linux From Scratch system with gcc 4.0.2 and uClibc...

Expect to be hearing from me a lot. :)

Rob


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Blaisorblade]

On Friday 18 November 2005 08:17, Rob Landley wrote:
> On Friday 18 November 2005 01:08, Blaisorblade wrote:
> > On Wednesday 16 November 2005 14:36, Rob Landley wrote:
> > > Linus said this:

Btw, where does this quote come from?

> > > > 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 don't quite get this +2/+5 discussion.

> > > > 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.

> > Definitely Jeff's tree is a first filter for his work, but I've not seen
> > it working a lot as a collector, especially for little fixes - but there
> > it makes sense.

> > I tend to send directly to Andrew and he forwards them to Linus (in many
> > cases so fast that I wonder if they appear in one -mm release), but I
> > currently do not have a public tree.

> So there currently _is_ no one UML tree that people interested in the most
> recent UML developments can check out.  We basically have to wait until it
> hits mainline.

Patches go in -mm first. Currently Andrew is often very quick at merging them.

Also, fixups tend to have less needs for testing - and they're often 
backported to -bs.

Also, I don't tend to merge big patches without first checking.

> That's sad.  I think I'll stick with Jeff's tree as the closest I've come
> so far...

> > > And applied them all (in series order) with a for loop.
> >
> > Can I suggest using quilt for this (as it's more powerful and easy to
> > use)?
> >
> > Especially when you add other patches as compile fixups...

> I'm not applying the other patches at the moment.  Right now I'm just
> trying to get Jeff's tree to build for me.

Which means applying your own fixups.

> If I have time tonight I'm 
> going to cherry-pick his patch list to see which ones I can get to compile,
> and give him the list of each one that breaks my build (and how).

I suggest quilt exactly because it automates one big task - managing the 
stacks of applied and unapplied patches. Will "patch" suggest you which patch 
is the top one? Quilt will. That's why I suggest you to try it.

> I just 
> mentioned that #2 of the recent 4 sent to Andrew broke the build for me,
> but that's not the only breakage I see from Jeff's tree.  (I currently have
> access to four different build environments.  I was focusing on the PLD
> x86-64 system I'm borrowing, but right now I'm focusing on my ubuntu
> laptop.  Then knoppix, and then my Linux From Scratch system with gcc 4.0.2
> and uClibc...

> Expect to be hearing from me a lot. :)

No problem... just be patient for fixes. And IMHO you shouldn't feel so shy 
about fixing such compile problems (no complaining!) I don't expect you to 
debug the stub problems, but the rest should be easier to work with.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.yahoo.com



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Rob Landley]

On Friday 18 November 2005 01:51, Blaisorblade wrote:
> On Friday 18 November 2005 08:17, Rob Landley wrote:
> > On Friday 18 November 2005 01:08, Blaisorblade wrote:
> > > On Wednesday 16 November 2005 14:36, Rob Landley wrote:
> > > > Linus said this:
>
> Btw, where does this quote come from?

Linux-kernel, last wednesday.

http://seclists.org/lists/linux-kernel/2005/Nov/3391.html

> > > > > 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 don't quite get this +2/+5 discussion.

Context from the rest of the thread, which started here:
http://seclists.org/lists/linux-kernel/2005/Nov/3290.html

n is release number.  It was about the 2 week merge window and the fact that 
it's a fairly sucky time to do new development.  (It's for merging stuff that 
you already got to work, and then bug fixes.)  The -mm tree is for shaking 
bugs out of stuff that worked for you, but may not get merged into linus's 
tree immediately.

> > > > > 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.
> > >
> > > Definitely Jeff's tree is a first filter for his work, but I've not
> > > seen it working a lot as a collector, especially for little fixes - but
> > > there it makes sense.
> > >
> > > I tend to send directly to Andrew and he forwards them to Linus (in
> > > many cases so fast that I wonder if they appear in one -mm release),
> > > but I currently do not have a public tree.
> >
> > So there currently _is_ no one UML tree that people interested in the
> > most recent UML developments can check out.  We basically have to wait
> > until it hits mainline.
>
> Patches go in -mm first. Currently Andrew is often very quick at merging
> them.

The problem is (as the discussion brought up), Andrew's tree integrates many 
things.  If you want to test _just_ one subsystem, there's usually a tree you 
can go to to get just -linus plus the new subsystem.

> Also, fixups tend to have less needs for testing - and they're often
> backported to -bs.

"backported"?  So is -bs more stable than mainline?  I thought it was your 
development tree...

> Also, I don't tend to merge big patches without first checking.

Testing -mm (except for fun) doesn't work for me because too much other stuff 
is in there and if something breaks I don't know what it is.  (It's nice to 
test it and be able to give a thumbs up if it passes.  But failure in -mm is 
not always a useful data point.  Certainly not without "ok, -linus plus 
-uml-current worked, so something else in -mm is breaking UML on x86-64 
building under PLD..."

> > I'm not applying the other patches at the moment.  Right now I'm just
> > trying to get Jeff's tree to build for me.
>
> Which means applying your own fixups.

When absolutely necessary, yes.  In theory Jeff's tree works for Jeff so i'm 
trying to get it to work for me _without_ fixing it myself.  (Instead I bug 
_him_. :)  But I'm on a wildly different distro (ubuntu on x86 and PLD on 
x86-64) and things like maszur's headers or the /lib64 thing I haven't got 
much choice to patch myself.

I try not to _keep_ these patches.  You'll notice I post them here in hopes 
mainline fixes the problem (whether my fix or a different one).

> > If I have time tonight I'm
> > going to cherry-pick his patch list to see which ones I can get to
> > compile, and give him the list of each one that breaks my build (and
> > how).
>
> I suggest quilt exactly because it automates one big task - managing the
> stacks of applied and unapplied patches. Will "patch" suggest you which
> patch is the top one?

What I'm currently doing is:

for in in `cat patches/series`
do
  echo $i
  patch -p1 -i patches/$i
done

I.E. I'm letting Jeff's "series" indicate which order they should go in.

I have nothing against quilt but learning new tools tends to go on my todo 
list.  I go down enough tangential ratholes in an average day as it is. :)

> Quilt will. That's why I suggest you to try it. 

I'm trying very hard to _avoid_ managing my own tree, thanks.  If I ever have 
more than about three patches I'm applying to the tree at once, it's time to 
either push to get them in mainline or upgrade to a newer version.

With the linux kernel I'm applying squashfs (which I would very much like to 
see in mainline but I seem to have missed that flamewar this time 'round), 
and one three line removal.  The rest is fixups to 2.6.15-rc1 that I hope to 
see in -rc2 or -rc3.

For systems I do lots of new development on, I just use subversion.

> > I just
> > mentioned that #2 of the recent 4 sent to Andrew broke the build for me,
> > but that's not the only breakage I see from Jeff's tree.  (I currently
> > have access to four different build environments.  I was focusing on the
> > PLD x86-64 system I'm borrowing, but right now I'm focusing on my ubuntu
> > laptop.  Then knoppix, and then my Linux From Scratch system with gcc
> > 4.0.2 and uClibc...
> >
> > Expect to be hearing from me a lot. :)
>
> No problem... just be patient for fixes.

I know. :)

> And IMHO you shouldn't feel so shy  about fixing such compile problems (no
> complaining!) I don't expect you to debug the stub problems, but the rest
> should be easier to work with. 

I fixed the header #include problem myself once I understood that Jeff had 
never used Mazur's headers.  He took my patch for that.

The /lib64 thing I have no _clue_ how the linker stage of the linux kernel 
works (it has a linker script to tell ld what to do, and does black magic 
with elf segments so it can put stuff into the init segment and make a module 
export list and...  Ummm..  Eek.)  I know my patch there is wrong (it breaks 
x86), figuring out what to do about that is a todo item..

The recent breakage I saw with patches.tar was too much damage for Jeff _not_ 
to have seen, so it was either some kind of compiler version problem where my 
patches were likely to break _his_ system, or else I didn't understand what 
was going on.  (And #2 was the case: once I found out it was the 0 length 
files, I could fix that.  I didn't expect 0 length files screwing up the 
#include search paths.  The #include search paths are confusing, I'm still a 
bit fuzzy on the difference between include and include2, actually...)

I'm happy to debug stuff myself, when I can.  And to submit patches...

Rob


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Blaisorblade]

On Friday 18 November 2005 09:41, Rob Landley wrote:
> On Friday 18 November 2005 01:51, Blaisorblade wrote:
> > On Friday 18 November 2005 08:17, Rob Landley wrote:
> > > On Friday 18 November 2005 01:08, Blaisorblade wrote:
> > > > On Wednesday 16 November 2005 14:36, Rob Landley wrote:
> > > > > Linus said this:
> >
> > Btw, where does this quote come from?

Thanks for the pointers...

> The problem is (as the discussion brought up), Andrew's tree integrates
> many things.  If you want to test _just_ one subsystem, there's usually a
> tree you can go to to get just -linus plus the new subsystem.

> > Also, fixups tend to have less needs for testing - and they're often
> > backported to -bs.

> "backported"?  So is -bs more stable than mainline?  I thought it was your
> development tree...

No, it stands for "Blaisorblade stable". When you see a -bb release, _that_ is 
for development (in recent times, I used it only for skas0 backport).

Btw, there is even a FAQ on the site... ("Frequently" could be called a joke 
probably, but during first months people were clearly showing my site was 
impossible to understand).

> > Also, I don't tend to merge big patches without first checking.

> Testing -mm (except for fun) doesn't work for me because too much other
> stuff is in there and if something breaks I don't know what it is.

Same reason for which I don't use it :-(


> When absolutely necessary, yes.  In theory Jeff's tree works for Jeff so
> i'm trying to get it to work for me _without_ fixing it myself.  (Instead I
> bug _him_. :)  But I'm on a wildly different distro (ubuntu on x86 and PLD
> on x86-64) and things like maszur's headers or the /lib64 thing I haven't
> got much choice to patch myself.

Btw, why hasn't maszur went to post patches to kernel headers to make them 
includable from userspace instead of merging kernel changes into his headers 
(which is much more work)? Kernel headers, notwithstanding with what Linus 
can say, _do_ use __KERNEL__ and are not sanitized enough (PTRACE_SETOPTIONS 
from 2.6 headers produces a binary not working on 2.4 hosts - you must switch 
to OLDSETOPTIONS).

> I try not to _keep_ these patches.  You'll notice I post them here in hopes
> mainline fixes the problem (whether my fix or a different one).

Hmm... ok, we've different needs - had I done that I wouldn't have got my 
patches merged in many cases (partially because Jeff knows I have my tree and 
I can merge things myself - he merges my patches adaptively).

> > And IMHO you shouldn't feel so shy  about fixing such compile problems
> > (no complaining!) I don't expect you to debug the stub problems, but the
> > rest should be easier to work with.

> I fixed the header #include problem myself once I understood that Jeff had
> never used Mazur's headers.  He took my patch for that.

> The /lib64 thing I have no _clue_ how the linker stage of the linux kernel
> works (it has a linker script to tell ld what to do, and does black magic
> with elf segments so it can put stuff into the init segment and make a
> module export list and...  Ummm..  Eek.)  I know my patch there is wrong
> (it breaks x86), figuring out what to do about that is a todo item..

Ok, done in the other mail.

> The recent breakage I saw with patches.tar was too much damage for Jeff
> _not_ to have seen, so it was either some kind of compiler version problem
> where my patches were likely to break _his_ system, or else I didn't
> understand what was going on.  (And #2 was the case: once I found out it
> was the 0 length files, I could fix that.  I didn't expect 0 length files
> screwing up the #include search paths.

No, we have something like 

include/asm-um/elf.h: 
	ln -s elf-$(SUBARCH).h include/asm-um/elf.h

and make considers the target built when the file exists.

> The #include search paths are 
> confusing, I'm still a bit fuzzy on the difference between include and
> include2, actually...)
Just look at them on a built tree.... 

$ ls -l $OUT/include
total 6
lrwxrwxrwx    1 paolo paolo    6 18 nov 09:06 asm -> asm-um
drwxr-xr-x    2 paolo paolo  328 18 nov 09:06 asm-um
drwxr-xr-x  119 paolo paolo 5744 18 nov 09:06 config
drwxr-xr-x    2 paolo paolo  144 19 nov 03:13 linux

$ ls -l $OUT/include2
total 0
lrwxrwxrwx  1 paolo paolo 59 19 nov 03:13 asm 
-> /home/paolo/Admin/kernel/6/VCS/linux-2.6.git/include/asm-um

As you see, in include there are directories for generated files; Kbuild 
creates include2 to generate the normal asm symlink in it, pointing to the 
original asm-$(ARCH).

There is a distinction between the "asm" directory for normal headers and the 
"asm" directory for build-generated headers.

Ah, for all the rest -I$(srctree)/include is also used, but as you can't 
create $(srctree)/include/asm, <asm/header.h> will not be found on it, even 
if header.h is not build-generated.

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.yahoo.com



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Rob Landley]

On Friday 18 November 2005 20:33, Blaisorblade wrote:
> > When absolutely necessary, yes.  In theory Jeff's tree works for Jeff so
> > i'm trying to get it to work for me _without_ fixing it myself.  (Instead
> > I bug _him_. :)  But I'm on a wildly different distro (ubuntu on x86 and
> > PLD on x86-64) and things like maszur's headers or the /lib64 thing I
> > haven't got much choice to patch myself.
>
> Btw, why hasn't maszur went to post patches to kernel headers to make them
> includable from userspace instead of merging kernel changes into his
> headers (which is much more work)?

For the same reason the glibc guys don't ship a patch against the kernel 
headers but ship cleaned upkernel headers.  It's much smaller and simpler, 
and the patch would break with every single release.  Besides, the patch 
isn't what we need to build libc, the cleaned up headers are.  It would add 
an unnecessary level of indirection and _never_ get merged into the main 
kernel?

Did I say never?  Yes, I did.  I take it you missed the periodic flamewars on 
this issue?  The kernel guys _actively_ don't care about userspace headers:
http://seclists.org/lists/linux-kernel/2003/Aug/5229.html

You read that right: stable userspace includable kernel headers were bumped to 
2.7, which ain't happening.  That was 2003.  Here's Linus Torvalds in 2004 
shooting down the next stab at it:
http://lwn.net/Articles/113349/

And my salvo in that discussion:
http://www.ussg.iu.edu/hypermail/linux/kernel/0412.0/0866.html

Mazur participated in this and got his head handed to him by Linus Torvalds.  
Random example of the exchange here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0411.3/1708.html

The kernel developers will sort of agree in theory that userspace needs to 
somehow know about the kernel API, but every single specific proposal ever 
brought up to clean up the kernel headers so userspace can more easily 
include them _always_ gets shot down because this work is not necessary to 
compile the linux kernel itself, and is therefore unnecessary churn from 
kernel developers' point of view.  (Userspace be damned.)

> Kernel headers, notwithstanding with 
> what Linus can say, _do_ use __KERNEL__ and are not sanitized enough
> (PTRACE_SETOPTIONS from 2.6 headers produces a binary not working on 2.4
> hosts - you must switch to OLDSETOPTIONS).

A periodic feature of the recurring flamewar is the proposal to remove all 
#ifdef __KERNEL__ notations from the kernel headers.  Here's an example from 
2001...

http://www.ussg.iu.edu/hypermail/linux/kernel/0107.2/0480.html

How serious they are about it varies from year to year...

Rob


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Rob Landley]

On Monday 21 November 2005 04:25, Nix wrote:
> On Fri, 18 Nov 2005, Rob Landley wrote:
> > On Friday 18 November 2005 20:33, Blaisorblade wrote:
> >> Btw, why hasn't maszur went to post patches to kernel headers to make
> >> them includable from userspace instead of merging kernel changes into
> >> his headers (which is much more work)?
> >
> > For the same reason the glibc guys don't ship a patch against the kernel
> > headers but ship cleaned upkernel headers.  It's much smaller and
> > simpler, and the patch would break with every single release.  Besides,
> > the patch isn't what we need to build libc, the cleaned up headers are. 
> > It would add an unnecessary level of indirection and _never_ get merged
> > into the main kernel?
>
> One problem is that Mariusz's linux-libc-headers work seems to have
> stalled :( the last headers out there are for 2.6.12, and increasingly much
> (e.g. iptables) needs to be pointed directly at the kernel headers again.
>
> I hope linux-libc-headers isn't dead. It looked like it was turning into
> a very good aggregation point, with patches coming in from Ubuntu and RH
> among others.

Hopefully he won't mind me quoting from his email on Nov 4th.  Project's not 
dead, he's just busy with Real Life (tm):

> I'm also CCing Wojtek Cieciwa (cieciwa@pld-linux.org), since he's one of the 
> guys that need a new llh release and I should be releasing 2.6.14.0 right 
> about now (my world kind of collapsed a few days ago and I'm out of the 
> picture for don't know how long; I hope to be able to recover within a week, 
> but who nows how things will work out; keep me CCed though).

Rob


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Nix]

On Mon, 21 Nov 2005, Rob Landley wrote:
> On Monday 21 November 2005 04:25, Nix wrote:
>> I hope linux-libc-headers isn't dead. It looked like it was turning into
>> a very good aggregation point, with patches coming in from Ubuntu and RH
>> among others.
> 
> Hopefully he won't mind me quoting from his email on Nov 4th.  Project's not 
> dead, he's just busy with Real Life (tm):

It sounds worse than `busy' to me.

>> I'm also CCing Wojtek Cieciwa (cieciwa@pld-linux.org), since he's one of the 
>> guys that need a new llh release and I should be releasing 2.6.14.0 right 

Murphy's Law says it'll come out in one day's time or something (I've
just finished rebuilding glibc-2.3.6, you see ;) ).

>> about now (my world kind of collapsed a few days ago

Mariusz, I hope things have improved and your world is a-building anew.

-- 
`Y'know, London's nice at this time of year. If you like your cities
 freezing cold and full of surly gits.' --- David Damerell



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Henrik Nordstrom]

On Fri, 18 Nov 2005, Rob Landley wrote:

> was going on.  (And #2 was the case: once I found out it was the 0 length
> files, I could fix that.  I didn't expect 0 length files screwing up the
> #include search paths.  The #include search paths are confusing, I'm still a
> bit fuzzy on the difference between include and include2, actually...)

0-length files after patching is generally due to slightly incorrectly 
formatted patches, and can screw up a lot of things.

From the patch man page:

   you can remove a file by sending out a context diff that compares
   the file to be deleted with an empty file dated the Epoch.  The
   file will be removed unless patch is conforming to POSIX and the
   -E or --remove-empty-files option is not given.

A few other formats also works, but what is said above is the safest patch 
format for removal of files.

If you find patches which removes files using a format not complying with 
the above then it may be wise to ask the person who published the patch to 
change his routines to make correctly formatted patches. On the sad side 
there is a number of widespread tools not generating such patches 
correctly (CVS is one.. have a cleanpatch script at devel.squid-cache.org 
fixing this and a few other CVS diff -u stupidities)

Regarding the include path, Compliers, make etc just searches their paths 
until a file is found, no attempt in verifying the validity of the file is 
made. If the found file is empty then in the input at that stage is 
empty, and if the actual file which was supposed to be found is in a later 
element in the search path then you get screwed.

Regards
Henrik


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Blaisorblade]

On Sunday 20 November 2005 00:40, Henrik Nordstrom wrote:
> On Fri, 18 Nov 2005, Rob Landley wrote:
> > was going on.  (And #2 was the case: once I found out it was the 0 length
> > files, I could fix that.  I didn't expect 0 length files screwing up the
> > #include search paths.  The #include search paths are confusing, I'm
> > still a bit fuzzy on the difference between include and include2,
> > actually...)

> 0-length files after patching is generally due to slightly incorrectly
> formatted patches, and can screw up a lot of things.

> From the patch man page:

>    you can remove a file by sending out a context diff that compares
>    the file to be deleted with an empty file dated the Epoch.  The
>    file will be removed unless patch is conforming to POSIX and the
>    -E or --remove-empty-files option is not given.

> A few other formats also works, but what is said above is the safest patch
> format for removal of files.

> If you find patches which removes files using a format not complying with
> the above then it may be wise to ask the person who published the patch to
> change his routines to make correctly formatted patches. On the sad side
> there is a number of widespread tools not generating such patches
> correctly (CVS is one.. have a cleanpatch script at devel.squid-cache.org
> fixing this and a few other CVS diff -u stupidities)

Hmm, quilt, git (and IIRC BitKeeper) don't comply with the above format, but 
they use /dev/null and it seems to work in practice. Jeff's version of quilt 
seems to be broken on this (he said he's using 0.32).

> Regarding the include path, Compliers, make etc just searches their paths
> until a file is found, no attempt in verifying the validity of the file is
> made. If the found file is empty then in the input at that stage is
> empty, and if the actual file which was supposed to be found is in a later
> element in the search path then you get screwed.

This case is a little different as I already explained...

In this case the 0-lenght file, when missing, would trigger make "building 
it" (i.e. creating it as a symlink with correct content).


-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.yahoo.com



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Jeff Dike]

On Fri, Nov 18, 2005 at 01:17:03AM -0600, Rob Landley wrote:
> > Definitely Jeff's tree is a first filter for his work, but I've not seen it
> > working a lot as a collector, especially for little fixes - but there it
> > makes sense.

I'd like it to be a collector of patches.  I just don't see a lot of them
(IIRC, the ones I do see are already on their way to akpm/linus, so it
makes not too much sense to exercise them in my tree).  Witness the OS
patches, the s390 stuff, and the NPTL patches (which I went and found
myself, which turned out to be a really good move).

> > I tend to send directly to Andrew and he forwards them to Linus (in many
> > cases so fast that I wonder if they appear in one -mm release), but I
> > currently do not have a public tree.

And you're welcome to send directly to Andrew, but feel free to send
them to me beforehand.


				Jeff


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Rob Landley]

On Friday 18 November 2005 17:52, Jeff Dike wrote:
> > > I tend to send directly to Andrew and he forwards them to Linus (in
> > > many cases so fast that I wonder if they appear in one -mm release),
> > > but I currently do not have a public tree.
>
> And you're welcome to send directly to Andrew, but feel free to send
> them to me beforehand.

Can I second the "send UML patches to Jeff and let him send them on to 
Andrew/Linus" approach?  Please?  It makes it much easier for me to test, 
with a known working system plus UML-only changes...

>     Jeff

Rob


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Jeff Dike]

On Fri, Nov 18, 2005 at 05:37:12PM -0600, Rob Landley wrote:
> Can I second the "send UML patches to Jeff and let him send them on to 
> Andrew/Linus" approach?  Please?  It makes it much easier for me to test, 
> with a known working system plus UML-only changes...

I never firsted this.  In fact, I want BB to send stuff around me.  He
has good judgement, and it saves me work.

I'll happily add things to my tree (and I'll add the stuff he sends
directly to akpm if it'll make things easier).

				Jeff


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: merge status

[Rob Landley]

On Friday 18 November 2005 18:55, Jeff Dike wrote:
> On Fri, Nov 18, 2005 at 05:37:12PM -0600, Rob Landley wrote:
> > Can I second the "send UML patches to Jeff and let him send them on to
> > Andrew/Linus" approach?  Please?  It makes it much easier for me to test,
> > with a known working system plus UML-only changes...
>
> I never firsted this.  In fact, I want BB to send stuff around me.  He
> has good judgement, and it saves me work.
>
> I'll happily add things to my tree (and I'll add the stuff he sends
> directly to akpm if it'll make things easier).

I just want one UML patch set I can apply against the most recent -linus to 
try out the new stuff.  How is entirely up to you guys. :)

Oh, speaking of which...

Rob


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: merge status

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

>>>>> "Jeff" == Jeff Dike <jdike@addtoit.com> writes:
    Jeff> On Fri, Nov 18, 2005 at 05:37:12PM -0600, Rob Landley wrote:
    >> Can I second the "send UML patches to Jeff and let him send them on to
    >> Andrew/Linus" approach?  Please?  It makes it much easier for me to
    >> test, with a known working system plus UML-only changes...

    Jeff> I never firsted this.  In fact, I want BB to send stuff around me.
    Jeff> He has good judgement, and it saves me work.

  So, BB should collect patches .... will you publish a git tree?

-- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

[-- Attachment #2: Type: application/pgp-signature, Size: 480 bytes --]

Re: [uml-devel] Re: merge status

[Blaisorblade]

On Wednesday 30 November 2005 18:23, Michael Richardson wrote:
> >>>>> "Jeff" == Jeff Dike <jdike@addtoit.com> writes:
>
>     Jeff> On Fri, Nov 18, 2005 at 05:37:12PM -0600, Rob Landley wrote:
>     >> Can I second the "send UML patches to Jeff and let him send them on
>     >> to Andrew/Linus" approach?  Please?  It makes it much easier for me
>     >> to test, with a known working system plus UML-only changes...
>
>     Jeff> I never firsted this.  In fact, I want BB to send stuff around
> me. Jeff> He has good judgement, and it saves me work.

>   So, BB should collect patches .... will you publish a git tree?

For now not - I've not the time to do this... also I work more in a quilt like 
style (I use quilt and StGit).

There are means to make a quilt-like tree (managed with StGit) exportable, but 
I've never coded them up (and their semantic is difficult to get right).
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade


		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.yahoo.com



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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.

git branches strategy (was Re: merge status)

[Jeff Garzik]

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

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