git trees which are not yet in linux-next

git trees which are not yet in linux-next

[Andrew Morton]

git-cifs: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6.git

git-gfs2-nmw: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-nmw.git

git-ieee1394: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git#for-mm

git-jg-misc: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git#irq-remove

git-libata-all: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-2.6.git

git-mips: git://git.linux-mips.org/pub/scm/upstream-akpm.git#mips-for-mm

git-mmc: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git#for-andrew

git-udf: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jack/linux-udf-2.6.git#for_mm

git-battery: git://git.infradead.org/battery-2.6.git

git-block: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git#for-akpm

git-v9fs: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git#v9fs-devel

git-watchdog: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog-mm.git

git-xtensa: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/czankel/xtensa-2.6.git#testing

git-orion: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/nico/orion.git

git-pekka: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6.git#for-mm


(This list is probably incomplete - there might be other trees which are
presently empty but which aren't in linux-next yet)

(Jeff, git-libata-all is a pretty important one)

Guys, could you please prepare a tree for Stephen and send the details
over to him?  Please Cc me also.

Once this has happened, there should be no need to run a separate for-mm
branch.  I'll just switch over to using whatever branch linux-next is
using.

I'll continue to pull all the git trees, although I'll expect to drop them
again.  I will do this to keep my list of git URLs fresh.  So if for some
reason linux-next isn't getting updated I can drop it and switch back to
the individual git trees.


I don't yet know how I'll get along basing -mm on linux-next.  The first
problem is working out "how the heck did that patch get into linux-next"? 
That would be much easier if the signoff trail was complete for git-based
patches, but it often is not.

Thanks.

(git-unionfs and such things will remain -mm-only)

Re: git trees which are not yet in linux-next

[Jeff Garzik]

Andrew Morton wrote:
> (Jeff, git-libata-all is a pretty important one)


libata-dev.git#NEXT is for linux-next, and libata-dev.git#ALL is for -mm

Already taken care of.

	Jeff

Re: git trees which are not yet in linux-next

[Andrew Morton]

On Fri, 02 May 2008 18:20:26 -0400
Jeff Garzik <jeff@garzik.org> wrote:

> Andrew Morton wrote:
> > (Jeff, git-libata-all is a pretty important one)
> 
> 
> libata-dev.git#NEXT is for linux-next, and libata-dev.git#ALL is for -mm
> 
> Already taken care of.
> 

Oh.  Something seems to have gone wrong then.

Next/Trees has:

libata          git     git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git#NEXT

but:

y:/usr/src/25> diffstat patches/linux-next.patch | grep /ata/      
y:/usr/src/25> 

There's nothing there?

(plans for git-jg-misc?)

Re: git trees which are not yet in linux-next

[Stephen Rothwell]

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

Hi Andrew,

On Fri, 2 May 2008 15:33:01 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 02 May 2008 18:20:26 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
> 
> > Andrew Morton wrote:
> > > (Jeff, git-libata-all is a pretty important one)
> > 
> > libata-dev.git#NEXT is for linux-next, and libata-dev.git#ALL is for -mm
> > 
> > Already taken care of.
> 
> Oh.  Something seems to have gone wrong then.
> 
> Next/Trees has:
> 
> libata          git     git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git#NEXT
> 
> but:
> 
> y:/usr/src/25> diffstat patches/linux-next.patch | grep /ata/      
> 
> There's nothing there?

This just means that everything that Jeff expected to go into 2.6.26 is
not in Linus' tree, right?  And he hasn't moved his 2.6.27 expectations
into linux-next yet (after all we are still in the 2.6.26 merge window).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: git trees which are not yet in linux-next

[Jeff Garzik]

Andrew Morton wrote:
> On Fri, 02 May 2008 18:20:26 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
> 
>> Andrew Morton wrote:
>>> (Jeff, git-libata-all is a pretty important one)
>>
>> libata-dev.git#NEXT is for linux-next, and libata-dev.git#ALL is for -mm
>>
>> Already taken care of.
>>
> 
> Oh.  Something seems to have gone wrong then.
> 
> Next/Trees has:
> 
> libata          git     git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git#NEXT
> 
> but:
> 
> y:/usr/src/25> diffstat patches/linux-next.patch | grep /ata/      
> y:/usr/src/25> 
> 
> There's nothing there?

Correct.  There is presently nothing waiting for linux-next.


> (plans for git-jg-misc?)

That's an ever-present bucket with ever-changing contents.  I put stuff 
in there when I have things for -mm testing, and hopefully, eventually 
upstream.

Sometimes jgarzik/misc-2.6.git#ALL might be empty (like libata-dev#NEXT 
is now), sometimes not.

The general point is to make sure both you and Stephen are pulling the 
right branches, which is sounds like you are.

	Jeff

Re: git trees which are not yet in linux-next

[Andrew Morton]

On Fri, 2 May 2008 15:12:06 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> The first
> problem is working out "how the heck did that patch get into linux-next"? 
> That would be much easier if the signoff trail was complete for git-based
> patches, but it often is not.

doh.  I'm pulling linux-next's constituent trees independently, so if I
spot a turd in linux-next I can just grep the various git trees to find out
where it came from.

It seems wrong though...

Re: git trees which are not yet in linux-next

[Stefan Richter]

Andrew Morton wrote:
> On Fri, 2 May 2008 15:12:06 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
>> The first
>> problem is working out "how the heck did that patch get into linux-next"? 
>> That would be much easier if the signoff trail was complete for git-based
>> patches, but it often is not.
> 
> doh.  I'm pulling linux-next's constituent trees independently, so if I
> spot a turd in linux-next I can just grep the various git trees to find out
> where it came from.
> 
> It seems wrong though...

What about the committer info?  Well, I suppose a nobody@localhost slips 
in, but more often I expect it to be something more telling than that.
-- 
Stefan Richter
-=====-==--- -=-= ---==
http://arcgraph.de/sr/

Re: git trees which are not yet in linux-next

[Andrew Morton]

On Sat, 03 May 2008 03:19:00 +0200 Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> Andrew Morton wrote:
> > On Fri, 2 May 2008 15:12:06 -0700
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> > 
> >> The first
> >> problem is working out "how the heck did that patch get into linux-next"? 
> >> That would be much easier if the signoff trail was complete for git-based
> >> patches, but it often is not.
> > 
> > doh.  I'm pulling linux-next's constituent trees independently, so if I
> > spot a turd in linux-next I can just grep the various git trees to find out
> > where it came from.
> > 
> > It seems wrong though...
> 
> What about the committer info?  Well, I suppose a nobody@localhost slips 
> in, but more often I expect it to be something more telling than that.

Beats me.  To pick one example:

commit 1a72963d3af38eb17a939fc19b322735da1c0aad
Author: Matthew Wilcox <matthew@wil.cx>
Date:   Fri Apr 25 12:38:41 2008 -0400

    Convert board-nokia770 from semaphore to spinlock
    
    None of the operations done under the semaphore could sleep, so a spinlock
    is more appropriate to this case.
    
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>

There's no sign how that got there.  A bit of forensics shows up:

semaphore-removal       git     git://git.kernel.org/pub/scm/linux/kernel/git/willy/misc.git#semaphore-removal                                                  

in Next/Trees.  I don't actually have that tree in -mm, which is a bit
unusual.  Otherwise a grep for `Convert board-nokia770 from semaphore to
spinlock' would have found it.

Oh well, don't worry - I'll work it out ;)

Re: git trees which are not yet in linux-next

[Jeff Garzik]

Andrew Morton wrote:
> On Sat, 03 May 2008 03:19:00 +0200 Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> 
>> Andrew Morton wrote:
>>> On Fri, 2 May 2008 15:12:06 -0700
>>> Andrew Morton <akpm@linux-foundation.org> wrote:
>>>
>>>> The first
>>>> problem is working out "how the heck did that patch get into linux-next"? 
>>>> That would be much easier if the signoff trail was complete for git-based
>>>> patches, but it often is not.
>>> doh.  I'm pulling linux-next's constituent trees independently, so if I
>>> spot a turd in linux-next I can just grep the various git trees to find out
>>> where it came from.
>>>
>>> It seems wrong though...
>> What about the committer info?  Well, I suppose a nobody@localhost slips 
>> in, but more often I expect it to be something more telling than that.
> 
> Beats me.  To pick one example:
> 
> commit 1a72963d3af38eb17a939fc19b322735da1c0aad
> Author: Matthew Wilcox <matthew@wil.cx>
> Date:   Fri Apr 25 12:38:41 2008 -0400
> 
>     Convert board-nokia770 from semaphore to spinlock
>     
>     None of the operations done under the semaphore could sleep, so a spinlock
>     is more appropriate to this case.
>     
> Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
> 
> There's no sign how that got there.  A bit of forensics shows up:

Poke through the man pages, particularly git-log, and tell it to spit 
out the committer info, then.  It's in there.

For example,

	git log --pretty=full

produces

	commit c4d0f8cbca3a97900f85b082064a63c7a5928bd7
	Author: Alan Cox <alan@lxorguk.ukuu.org.uk>
	Commit: Greg Kroah-Hartman <gregkh@suse.de>

	    usb_serial: some coding style fixes

	    Signed-off-by: Alan Cox <alan@redhat.com>
	    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Regards,

	Jeff

Re: git trees which are not yet in linux-next

[Stefan Richter]

Jeff Garzik wrote:
>>> Andrew Morton wrote:
>>>> On Fri, 2 May 2008 15:12:06 -0700
>>>> Andrew Morton <akpm@linux-foundation.org> wrote:
>>>>
>>>>> The first
>>>>> problem is working out "how the heck did that patch get into 
>>>>> linux-next"? That would be much easier if the signoff trail was 
>>>>> complete for git-based
>>>>> patches, but it often is not.
>>>> doh.  I'm pulling linux-next's constituent trees independently, so if I
>>>> spot a turd in linux-next I can just grep the various git trees to 
>>>> find out
>>>> where it came from.
...
> Poke through the man pages, particularly git-log, and tell it to spit 
> out the committer info, then.  It's in there.
> 
> For example,
> 
>     git log --pretty=full
...

Of course some committers have more than one tree in -next.  So if 
Andrew wants to know the actual tree, the laziest method which I know of is
$ gitk <commit_id>

Among else, gitk shows which branches contain the commit.  (How to do 
this without X GUI?)
-- 
Stefan Richter
-=====-==--- -=-= ---==
http://arcgraph.de/sr/

Re: git trees which are not yet in linux-next

[Stephen Rothwell]

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

On Sat, 03 May 2008 10:46:39 +0200 Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>
> Of course some committers have more than one tree in -next.  So if 
> Andrew wants to know the actual tree, the laziest method which I know of is
> $ gitk <commit_id>
> 
> Among else, gitk shows which branches contain the commit.  (How to do 
> this without X GUI?)

Unfortunately, this will not work either as I do not export to the public
tree the heads of each of the branches that I merge.  It does work in my
tree until I do the next update.

However, if you look at the closest following merge that is committed by
me, that will tell you which branch the commit was on.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: git trees which are not yet in linux-next

[Stefan Richter]

Andrew Morton wrote:
> git-ieee1394: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git#for-mm

Stephen pulls linux1394-2.6.git#for-next.

> Guys, could you please prepare a tree for Stephen and send the details
> over to him?  Please Cc me also.
> 
> Once this has happened, there should be no need to run a separate for-mm
> branch.  I'll just switch over to using whatever branch linux-next is
> using.

-mm is going to become identical in content to -next?
-- 
Stefan Richter
-=====-==--- -=-= ---==
http://arcgraph.de/sr/

Re: git trees which are not yet in linux-next

[Andrew Morton]

On Sat, 03 May 2008 03:11:25 +0200 Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> Andrew Morton wrote:
> > git-ieee1394: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git#for-mm
> 
> Stephen pulls linux1394-2.6.git#for-next.
> 
> > Guys, could you please prepare a tree for Stephen and send the details
> > over to him?  Please Cc me also.
> > 
> > Once this has happened, there should be no need to run a separate for-mm
> > branch.  I'll just switch over to using whatever branch linux-next is
> > using.
> 
> -mm is going to become identical in content to -next?

-mm will be (and now is)

origin.patch
linux-next.patch
<other patches>

Where "other patches" includes git trees which aren't in linux-next.

So yes, you should drop #for-mm and add #for-next.

I will pull your #for-next brach daily, but I'll only include it (as
git-ieee1394.patch) if for some reason linux-next.patch needed to be
dropped.

Re: git trees which are not yet in linux-next

[Liam Girdwood]

On Fri, 2008-05-02 at 15:12 -0700, Andrew Morton wrote:

> 
> (This list is probably incomplete - there might be other trees which are
> presently empty but which aren't in linux-next yet)

Any chance the voltage/current regulator tree could be added :-

git-regulator: git://opensource.wolfsonmicro.com/linux-2.6-audioplus.git#for-akpm

Thanks

Liam

Re: git trees which are not yet in linux-next

[Andrew Morton]

On Mon, 05 May 2008 17:52:16 +0100
Liam Girdwood <lg@opensource.wolfsonmicro.com> wrote:

> On Fri, 2008-05-02 at 15:12 -0700, Andrew Morton wrote:
> 
> > 
> > (This list is probably incomplete - there might be other trees which are
> > presently empty but which aren't in linux-next yet)
> 
> Any chance the voltage/current regulator tree could be added :-
> 
> git-regulator: git://opensource.wolfsonmicro.com/linux-2.6-audioplus.git#for-akpm
> 

Yup, I added that, thanks.

Re: git trees which are not yet in linux-next

[Stephen Rothwell]

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

On Mon, 5 May 2008 10:57:28 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Mon, 05 May 2008 17:52:16 +0100
> Liam Girdwood <lg@opensource.wolfsonmicro.com> wrote:
> 
> > On Fri, 2008-05-02 at 15:12 -0700, Andrew Morton wrote:
> > 
> > > 
> > > (This list is probably incomplete - there might be other trees which are
> > > presently empty but which aren't in linux-next yet)
> > 
> > Any chance the voltage/current regulator tree could be added :-
> > 
> > git-regulator: git://opensource.wolfsonmicro.com/linux-2.6-audioplus.git#for-akpm
> > 
> 
> Yup, I added that, thanks.

Was there a request in there for linux-next as well?  ;-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: git trees which are not yet in linux-next

[Andrew Morton]

On Tue, 6 May 2008 14:45:49 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> On Mon, 5 May 2008 10:57:28 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Mon, 05 May 2008 17:52:16 +0100
> > Liam Girdwood <lg@opensource.wolfsonmicro.com> wrote:
> > 
> > > On Fri, 2008-05-02 at 15:12 -0700, Andrew Morton wrote:
> > > 
> > > > 
> > > > (This list is probably incomplete - there might be other trees which are
> > > > presently empty but which aren't in linux-next yet)
> > > 
> > > Any chance the voltage/current regulator tree could be added :-
> > > 
> > > ___git-regulator: git://opensource.wolfsonmicro.com/linux-2.6-audioplus.git#for-akpm
> > > 
> > 
> > Yup, I added that, thanks.
> 
> Was there a request in there for linux-next as well?  ;-)

I thought about it.  It's a once-off tree rather than a permanent thing. 
Do you do those?

Getting it into linux-next would of course give better testing coverage.

Re: git trees which are not yet in linux-next

[Stephen Rothwell]

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

On Mon, 5 May 2008 22:50:09 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Tue, 6 May 2008 14:45:49 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Was there a request in there for linux-next as well?  ;-)
> 
> I thought about it.  It's a once-off tree rather than a permanent thing. 
> Do you do those?

I do, as long as I am kept informed.  Willy's semaphore trees for example.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: git trees which are not yet in linux-next

[Pekka Enberg]

Hi Andrew,

On Sat, May 3, 2008 at 1:12 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
>  Guys, could you please prepare a tree for Stephen and send the details
>  over to him?  Please Cc me also.
>
>  Once this has happened, there should be no need to run a separate for-mm
>  branch.  I'll just switch over to using whatever branch linux-next is
>  using.

I was looking at preparing a for-next branch for the SLAB tree but I'm
not sure I understand the above. For something like the slab
allocator, you want as much exposure as possible before asking Linus
to pull so I would like to continue to (ab)use -mm for testing as
well. But that doesn't seem to fit the linux-next rules at all...

So what to do here? I don't have a problem with maintaining separate
branches for mm and next where the latter is not going to get much
action until very late in the release cycle when I'm preparing for the
next merge window.

                        Pekka

Re: git trees which are not yet in linux-next

[Andrew Morton]

On Mon, 5 May 2008 21:16:12 +0300
"Pekka Enberg" <penberg@cs.helsinki.fi> wrote:

> Hi Andrew,
> 
> On Sat, May 3, 2008 at 1:12 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> >  Guys, could you please prepare a tree for Stephen and send the details
> >  over to him?  Please Cc me also.
> >
> >  Once this has happened, there should be no need to run a separate for-mm
> >  branch.  I'll just switch over to using whatever branch linux-next is
> >  using.
> 
> I was looking at preparing a for-next branch for the SLAB tree but I'm
> not sure I understand the above. For something like the slab
> allocator, you want as much exposure as possible before asking Linus
> to pull so I would like to continue to (ab)use -mm for testing as
> well. But that doesn't seem to fit the linux-next rules at all...

You have stuff in your tree which isn't intended for 2.6.27??

> So what to do here? I don't have a problem with maintaining separate
> branches for mm and next where the latter is not going to get much
> action until very late in the release cycle when I'm preparing for the
> next merge window.

I don't mind, really - just do what you think is best for your subsystem
and then tell me and Stephen about it.  We'll only notice if you break
stuff ;)

So I'd suggest that you have a #for-next which contains material for 2.6.26
and 2.6.27 and a #for-mm which contains material for 2.6.28+.

Only problem is, I'd need to generate the #for-next -> #for-mm diff, and
that particular git operation has been troublesome in the past.

otoh, I think that staging for-2.6.26 and for-2.6.27 material in -mm really
is reaching far enough into the future, and I'd question the value of
staging for-2.6.28+ material as well.  I mean, that's half a year away.

Re: git trees which are not yet in linux-next

[Pekka J Enberg]

On Mon, 5 May 2008 21:16:12 +0300
"Pekka Enberg" <penberg@cs.helsinki.fi> wrote:
> > I was looking at preparing a for-next branch for the SLAB tree but I'm
> > not sure I understand the above. For something like the slab
> > allocator, you want as much exposure as possible before asking Linus
> > to pull so I would like to continue to (ab)use -mm for testing as
> > well. But that doesn't seem to fit the linux-next rules at all...
 
On Mon, 5 May 2008, Andrew Morton wrote:
> You have stuff in your tree which isn't intended for 2.6.27??

Heh, no, but I did read somewhere that you're only supposed to put patches 
in 'next' that you consider to be good enough for Linus to pull.

On Mon, 5 May 2008 21:16:12 +0300
"Pekka Enberg" <penberg@cs.helsinki.fi> wrote:
> > So what to do here? I don't have a problem with maintaining separate
> > branches for mm and next where the latter is not going to get much
> > action until very late in the release cycle when I'm preparing for the
> > next merge window.

On Mon, 5 May 2008, Andrew Morton wrote:
> I don't mind, really - just do what you think is best for your subsystem
> and then tell me and Stephen about it.  We'll only notice if you break
> stuff ;)
> 
> So I'd suggest that you have a #for-next which contains material for 2.6.26
> and 2.6.27 and a #for-mm which contains material for 2.6.28+.
> 
> Only problem is, I'd need to generate the #for-next -> #for-mm diff, and
> that particular git operation has been troublesome in the past.
> 
> otoh, I think that staging for-2.6.26 and for-2.6.27 material in -mm really
> is reaching far enough into the future, and I'd question the value of
> staging for-2.6.28+ material as well.  I mean, that's half a year away.

Well, I only really have three kinds of patches: (1) testing, (2) 
for-linus asap (fixes in the middle of a release cycle) and (3) for-linus 
when the merge window opens. Up until now, I've put (1) in for-mm and 
after enough exposure (and no bug reports) they graduate into (2) or (3).

So the problem here is where I put the patches in category (1)? If 
they can go into for-next, then for-mm can disappear. Stephen?

		Pekka

Re: git trees which are not yet in linux-next

[Stefan Richter]

Pekka J Enberg wrote:
> Well, I only really have three kinds of patches: (1) testing, (2) 
> for-linus asap (fixes in the middle of a release cycle) and (3) for-linus 
> when the merge window opens. Up until now, I've put (1) in for-mm and 
> after enough exposure (and no bug reports) they graduate into (2) or (3).
> 
> So the problem here is where I put the patches in category (1)?

(1) Testing = (1a) testing isolated changes, (1b) testing in integration 
with other pending changes.  -next is for the latter kind of tests, 
AFAIU with the primary goal of sorting out integration related issues. 
For several reasons --- for example one reason which I saw mentioned was 
to attract more testers than maybe -mm had lately --- we have been asked 
to submit code to -next which has passed (1a)-type testing and had 
appropriate review.

Needless to say, many of us have difficulties to acquire resources 
[time, hardware, test cases/ workloads] for (1) or (1a).  OTOH, 
borrowing -next or -mm for too early test stages will not pay out for 
any of us in the long run.
-- 
Stefan Richter
-=====-==--- -=-= --=-=
http://arcgraph.de/sr/

Re: git trees which are not yet in linux-next

[Daniel Hazelton]

On Monday 05 May 2008 14:41:53 Pekka J Enberg wrote:
> On Mon, 5 May 2008 21:16:12 +0300
>
> "Pekka Enberg" <penberg@cs.helsinki.fi> wrote:
> > > I was looking at preparing a for-next branch for the SLAB tree but I'm
> > > not sure I understand the above. For something like the slab
> > > allocator, you want as much exposure as possible before asking Linus
> > > to pull so I would like to continue to (ab)use -mm for testing as
> > > well. But that doesn't seem to fit the linux-next rules at all...
>
> On Mon, 5 May 2008, Andrew Morton wrote:
> > You have stuff in your tree which isn't intended for 2.6.27??
>
> Heh, no, but I did read somewhere that you're only supposed to put patches
> in 'next' that you consider to be good enough for Linus to pull.
>
> On Mon, 5 May 2008 21:16:12 +0300
>
> "Pekka Enberg" <penberg@cs.helsinki.fi> wrote:
> > > So what to do here? I don't have a problem with maintaining separate
> > > branches for mm and next where the latter is not going to get much
> > > action until very late in the release cycle when I'm preparing for the
> > > next merge window.
>
> On Mon, 5 May 2008, Andrew Morton wrote:
> > I don't mind, really - just do what you think is best for your subsystem
> > and then tell me and Stephen about it.  We'll only notice if you break
> > stuff ;)
> >
> > So I'd suggest that you have a #for-next which contains material for
> > 2.6.26 and 2.6.27 and a #for-mm which contains material for 2.6.28+.
> >
> > Only problem is, I'd need to generate the #for-next -> #for-mm diff, and
> > that particular git operation has been troublesome in the past.
> >
> > otoh, I think that staging for-2.6.26 and for-2.6.27 material in -mm
> > really is reaching far enough into the future, and I'd question the value
> > of staging for-2.6.28+ material as well.  I mean, that's half a year
> > away.
>
> Well, I only really have three kinds of patches: (1) testing, (2)
> for-linus asap (fixes in the middle of a release cycle) and (3) for-linus
> when the merge window opens. Up until now, I've put (1) in for-mm and
> after enough exposure (and no bug reports) they graduate into (2) or (3).
>
> So the problem here is where I put the patches in category (1)? If
> they can go into for-next, then for-mm can disappear. Stephen?
>
> 		Pekka
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

I think (1) would be for-mm, (2) would be pushed to Linus ASAP and (3) would 
be for-next. (unless I've gotten the intent of the various trees mixed up 
somewhere while tracking this discussion)

DRH

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.

Re: git trees which are not yet in linux-next

[Stephen Rothwell]

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

Hi Pekka,

On Mon, 5 May 2008 21:41:53 +0300 (EEST) Pekka J Enberg <penberg@cs.helsinki.fi> wrote:
>
> Well, I only really have three kinds of patches: (1) testing, (2) 
> for-linus asap (fixes in the middle of a release cycle) and (3) for-linus 
> when the merge window opens. Up until now, I've put (1) in for-mm and 
> after enough exposure (and no bug reports) they graduate into (2) or (3).
> 
> So the problem here is where I put the patches in category (1)? If 
> they can go into for-next, then for-mm can disappear. Stephen?

Stefan Richter is right: if they have passed your review and testing in
isolation, then they are allowed into -next for testing against other
subsystems. So (2), (3), and (1b) ... :-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: git trees which are not yet in linux-next

[Stephen Rothwell]

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

On Mon, 5 May 2008 11:31:28 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> So I'd suggest that you have a #for-next which contains material for 2.6.26
> and 2.6.27 and a #for-mm which contains material for 2.6.28+.
> 
> Only problem is, I'd need to generate the #for-next -> #for-mm diff, and
> that particular git operation has been troublesome in the past.

Yeah, it is fine if one is a subset of the other but otherwise fraught
with danger.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: git trees which are not yet in linux-next

[Pierre Ossman]

On Fri, 2 May 2008 15:12:06 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> 
> git-mmc: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git#for-andrew
> 

The stuff I've pushed to Andrew has always been what I've been hoping
to merge in the next window, so it should just be a matter of renaming
the branch. There is a #next at the above URI now.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  rdesktop, core developer          http://www.rdesktop.org

Re: git trees which are not yet in linux-next

[Stephen Rothwell]

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

Hi Pierre,

On Tue, 13 May 2008 08:36:15 +0200 Pierre Ossman <drzeus-list@drzeus.cx> wrote:
>
> On Fri, 2 May 2008 15:12:06 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > 
> > git-mmc: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git#for-andrew
> > 
> 
> The stuff I've pushed to Andrew has always been what I've been hoping
> to merge in the next window, so it should just be a matter of renaming
> the branch. There is a #next at the above URI now.

I have added that for tomorrow, thanks.

I noticed that that tree also has a for-linus branch.  Would that be bug
fixes and stuff lined up for this release i.e. 2.6.26?  If so, I could
add that to linux-next as well as one of the early merge trees.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: git trees which are not yet in linux-next

[Pierre Ossman]

On Tue, 13 May 2008 17:00:52 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Pierre,
> 
> On Tue, 13 May 2008 08:36:15 +0200 Pierre Ossman <drzeus-list@drzeus.cx> wrote:
> > 
> > The stuff I've pushed to Andrew has always been what I've been hoping
> > to merge in the next window, so it should just be a matter of renaming
> > the branch. There is a #next at the above URI now.
> 
> I have added that for tomorrow, thanks.
> 
> I noticed that that tree also has a for-linus branch.  Would that be bug
> fixes and stuff lined up for this release i.e. 2.6.26?  If so, I could
> add that to linux-next as well as one of the early merge trees.
> 

That's correct. But I've always made sure that for-linus is the base for
for-andrew (now next), so that should not be necessary.

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  rdesktop, core developer          http://www.rdesktop.org

Re: git trees which are not yet in linux-next

[Stephen Rothwell]

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

Hi Pierre,

On Tue, 13 May 2008 12:47:45 +0200 Pierre Ossman <drzeus-list@drzeus.cx> wrote:
>
> That's correct. But I've always made sure that for-linus is the base for
> for-andrew (now next), so that should not be necessary.

What it allows me to do, though, is drop your "next" tree if things go
really bad without dropping fixes for Linus' current tree that you deem
necessary.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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