| |
|
 |
|
 |
|
|
|
| |
|
|
xen-merge
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
|
|
|
| |
|
Home