Re: A question of workflow

[Matthew Palmer <mpalmer@hezmatt.org>]

On Sun, Jan 07, 2007 at 02:46:38PM -0800, Justin Patrin wrote:
> You know, instead of adding extra branches and making the workflow mor
> complicated for core devs you, as an external contributor, could
> follow your patch as it makes it into OE and update your local version
> accordingly. That way you also have no conflicts when you propagate or
> merge.

Or I could just not submit the patch to OE.  That way I would also have no
conflicts.  Not so good for OE, but the same end result for me.  Keeping
track of a large number of patches in any particular state wouldn't be a
whole load of fun, either, especially when there's a tool which, in theory,
should be doing that work for me.

> One thing I could see us doing is possibly comitting a patch as-is and
> then making changes and comitting that. (Of course, we wouldn't push
> until it's all finished) but I don't know how well that will merge.
> Monotone uses the revision graph to deal with merging and your local
> commit still wouldn't likely be the same revision as what the dev
> comitted.

Or you could merge the patch directly from the user's tree, which keeps all
the metadata intact.  Monotone seems particularly poor in this regard,
requiring you to be running your own mtnserve, though.

> It should also be noted that it doesn't take too much to get to be an
> OE dev yourself. You can keep your own branch and deal with a few
> merge conflicts, then get commit access to OE and commit/push
> directly.

That shouldn't be necessary.

- Matt

-- 
If Alan Turing was alive today, the homosexuality would be OK but he'd be in    
trouble for codebreaking.
		-- Martin Bacon