[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-merge] xen subarch



> Arjan pointed out a big problem with trees like this: they 
> contain all changes in one big tree, while Linus prefers 
> smaller, individually digestible chunks.

I don't think we'll actually want to point Linus at this tree.

I think we'll want to break bits out of this tree into a series of
patches that get fed to Linus/Andrew. If they accept them, we'll get
them back when we do a pull & merge.

Changesets within the merge tree should be useful for helping select
patches to break out, but the initial set of patches we'll want to send
upstream will just be cleanups and not contain the xen subarch part at
all.

I'm totally open to other suggestions, though. Perhaps we should have a
directory of broken-out patches as part of the linux tree?

Ian
 
> I wonder if it would make more sense to maintain all of 
> Xenolinux as a big quilt patchset ?
> 
> It may make Xenolinux maintenance a little bit harder, but it 
> should make it a lot easier to merge things upstream.
> 
> No, I don't know whether this would actually improve things; 
> this is just something to think about...
> 
> --
> All Rights Reversed
> 

_______________________________________________
Xen-merge mailing list
Xen-merge@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-merge


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.