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 in...
[ message continues ]

On Fri, 2 May 2008 15:12:06 -0700

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

Hi Pierre,

On Tue, 13 May 2008 08:36:15 +0200 Pierre Ossman <drzeus-list@drzeus.cx> wr=

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.

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

On Tue, 13 May 2008 17:00:52 +1000

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

Hi Pierre,

On Tue, 13 May 2008 12:47:45 +0200 Pierre Ossman <drzeus-list@drzeus.cx> wr=

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.

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

Hi Andrew,


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

On Mon, 5 May 2008 21:16:12 +0300


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

On Mon, 5 May 2008 11:31:28 -0700 Andrew Morton <akpm@linux-foundation.org>=

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

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

On Mon, 5 May 2008 21:16:12 +0300
 

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


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

Hi Pekka,

On Mon, 5 May 2008 21:41:53 +0300 (EEST) Pekka J Enberg <penberg@cs.helsink=

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

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

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

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

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

--

On Mon, 05 May 2008 17:52:16 +0100

Yup, I added that, thanks.
--

On Mon, 5 May 2008 10:57:28 -0700 Andrew Morton <akpm@linux-foundation.org>=

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

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

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

On Mon, 5 May 2008 22:50:09 -0700 Andrew Morton <akpm@linux-foundation.org>=

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

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

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

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

--

On Fri, 2 May 2008 15:12:06 -0700

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

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 ;)


--

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



--

...

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

On Sat, 03 May 2008 10:46:39 +0200 Stefan Richter <stefanr@s5r6.in-berlin.d=

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.

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

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

Already taken care of.

	Jeff


--

On Fri, 02 May 2008 18:20:26 -0400

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?)
--

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



--

Hi Andrew,

On Fri, 2 May 2008 15:33:01 -0700 Andrew Morton <akpm@linux-foundation.org>=

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

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