On Jan 3, 2007, at 12:01 PM, Hollis Blanchard wrote:
On Sun, 2006-12-17 at 18:00 +0000, Xen patchbot-xenppc-unstable wrote:
# HG changeset patch
# User Jimi Xenidis <[EMAIL PROTECTED]>
# Node ID b04e24db308f2215c6bafaf358d1c10da79f244f
# Parent 965d3e42dddaf5971001f7d172d192f925537644
[XEN][POWERPC] get cpu_*_maps correct so physinfo and affinity is
Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
Please commit all uncontroversial patches first to xenppc-merge, then
pull xenppc-merge into xenppc-unstable.
Unfortunately, the above patch was controversial and the rework in on
my queue, but thats not the point here.
It's OK if we change our minds
later and revert changesets in -merge.
To recap, xenppc-merge contains patches going upstream; it is pulled
directly into xen-unstable. xenppc-unstable is xen-unstable plus any
temporary hacks we need to make progress. (When you define
xenppc-unstable this way, it obviously should be a child tree, not a
I think this model is premature since the only purpose of -merge is
to be a consistent pull tree.
Unfortunately, -merge is incomplete, may not run or even build, we
cannot base work on that.
This will ensure that we never have the same difficulty staying in
with xen-unstable that we've had in the past.
I'm not sure how..
Are you asking all developers to send diffs based on the -merge tree?
Are you asking the maintainers to go thru the following process?
1) apply diffs to childof-unstable, test
2) apply to childof-merge and then push -merg blind
3) pull -merge into -unstable
4) reset childof-unstable
I think we need to get -unstable to a point where patches are
acceptable make the tip of -merge be that "snapshot" and continue
working in -unstable.
So lets bear down and get whatever change set that is in -unstable
We can consider what you propose when -merge works completely
Xen-ppc-devel mailing list