On Tue, 2008-02-12 at 12:02 +1100, Stephen Rothwell wrote:
quoted text
> Hi all,
> 
> Andrew was looking for someone to run a linux-next tree that just
> contained the subsystem git and quilt trees for 2.6.x+1 and I (in a
> moment of madness) volunteered.  So, this is to announce the creating of
> such a tree (it doesn't exist yet) which will require some (hopefully)
> small amount of work on the part of subsystem maintainers.

Actually, it sort of does.  If you look here:

http://www.kernel.org/pub/linux/kernel/people/jejb/merge-tree/

You'll find a merge candidate tree that builds nightly from everyone's
git and quilt trees.  I'm using it to track merge conflicts (so I only
build the patch, I don't check it compiles).

You're welcome to the scripts that do this:

http://www.kernel.org/pub/linux/kernel/people/jejb/build.pl

And the config file that runs it:

http://www.kernel.org/pub/linux/kernel/people/jejb/merge-tree-build

I don't plan to do much more than keep it building to check conflicts,
so you're welcome to take it over.

quoted text
> Those interested in discussion about this are encouraged to join the
> linux-next@vger.kernel.org mailing list.
> 
> The first things I need from the subsystem maintainers (you know who you
> are) are a contact address (a list address is fine) and at least one git
> branch or quilt series that contains all the things you want to see go
> into 2.6.26.  I am happy for there to be multiple branches/series (in
> fact there probably will need to be in some cases where there are
> dependencies on others work).
> 
> The tree will be based on the current version of Linus' tree but you may
> specify an earlier branch point if you need to (hopefully not - but more
> likely for quilters, I guess).
> 
> I hope to recreate this tree every day automatically.  In order to do
> this, any tree that has a conflict will be dropped from that days tree.
> The maintainer will be notified.  I hope to provide some clue as to what
> the conflict is with, but probably not initially.

Actually the experiment with the -mc tree shows that most of the
conflicts are trivial in nature (usually docbook stuff or
feature-removal.txt stuff), so you can do a trivial triage by hand.  You
can't automatically drop them (well, not unless you want to end up
dropping half the trees).

The other problem is that we actually maintain deliberate conflicts with
a last person to merge fixes it type attitude.  Again, it's usually in
minor areas, and the fixups are fairly trivial, but it illustrates why
conflicts can't be a reason to drop a tree, you have to maintain some
sort of automatic fixup (at least I had to with the -mc tree).  The
reason we do this is that it would give the maintainers a nasty web of
included trees (which is almost impossible for the quilt trees anyway)
if we tried to resolve the conflicts and destroy our ability to rebase.

quoted text
> I will attempt to build the tree between each merge (and a failed build
> will again cause the offending tree to be dropped).  These builds will be
> necessarily restricted to probably one architecture/config.  I will build
> the entire tree on as many architectures/configs as seem sensible and
> the results of that will be available on a web page (to be announced).

Yes, this is the bit I've never dared do ... principally because it's
such a time sink.

James


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