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 accurate

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
parent tree.)

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 sync
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 into -merge.

We can consider what you propose when -merge works completely


Xen-ppc-devel mailing list

Reply via email to