On Sat, 3 May 2008 15:45:42 +1000 Stephen Rothwell <sfr@canb.auug.org.au> w=

In case it isn't clear, I need to be told where I can get a particular
tree from and who should be contacted in case of problems (I do not troll
through the MAINTAINERS file).  I can currently handle git trees and
quilt series.  I am willing to consider other formats/scms.  I also do
not mind having multiple trees (or branches or series files) for a single
subsystem/maintainer.

Series files must be annotated with an indication of the place in Linus'
tree that they are based on using the following format:

# BASE <some identification of a place in Linus' tree>

This base can be a SHA1 or a release tag or one of the ...-git<n> or the
output from "git describe".  Alternatively, you can be based on another
tree in linux-next by using:

# NEXT_BASE <name of a tree in linux-next>

The names are in the Next/Trees file in each release and normally do not
change.

Also you may (if you like) delimit the parts of the series you want in
linux-next by using:

# NEXT_PATCHES_START
.
.
# NEXT_PATCHES_END

There can be multiple such sections.

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

What do we use for BASE or NEXT_BASE if the base tree is linux-next?


---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
--

[ message continues ]

Hi Randy,

On Tue, 22 Jul 2008 15:31:14 -0700 Randy Dunlap <randy.dunlap@oracle.com> w=

The name from the Next/Trees file in any linux-next release.  You should
be very careful doing this if you don't control the other tree, though.
And you should let me know so that I can order the trees appropriately.

This was mainly added for Greg who has 4 quilt series in linux-next that
depend on each other.  If you depend on some random tree that changes day
to day your quilt series may no longer apply cleanly on top of it.

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

mips, m32r, parisc and xtensa do have git trees.  The rest are mastered as
discrete patches in -mm.

Except for m68knommu, which pops unexpectedly out of the woodwork during
the merge window.  I've asked that this be altered ;)
--

[ message continues ]

On Fri, 2 May 2008 23:35:19 -0700 Andrew Morton <akpm@linux-foundation.org>=

So, I was wondering if it would be worth while having subsections to a
series file like:

# NEXT_PATCHES_START [<label> [<base>]]

# NEXT_PATCHES_END

With <label> sections being logically separate enough that we can talk
about them/drop them/merge them at different places etc.


Yeah, I saw that, thanks.

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

That sounds good.  I once started to think about how to do this but
accidentally fell asleep.  I was thinking along the lines of the above,
only it drives an akpm script which spits out separate quilt (or git) trees
for linux-next.

The problem is that I then need to "drop" the patches so that I can merge
linux-next.  That's where I fell asleep.  I suppose that putting the
well-baked ones into a git tree and mastering them there solves the
problem.  But juggling 100-odd git branches on top of everything else
doesn't sound fun.

I need to think about this some more - it'll come.

What does "[<base>]" do?

--

[ message continues ]

On Fri, 2 May 2008 23:35:19 -0700 Andrew Morton <akpm@linux-foundation.org>=

So (from the above list) cris, m68knommu and mips have joined the
linux-next fray ...

(cc's some maintainers)
--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[ message continues ]

Internally I have both of these trees split into "current" and "next"
sections, so that I know what to merge when.

If it would make things easier for you, I'd be glad to split both of
these trees up in such a manner to make it more visable.

Perhaps:
	driver-core-next
	usb-next
	driver-core
	usb


ldp you have properly named as something that will probably go into
next-next or most likely next-next-next, but does build and run properly
today, yet has work to go in the "must clean up this crap" arena.

thanks,

greg k-h
--

[ message continues ]