[oe] A question of workflow

[Patrick Ohly]

On So, 2006-12-31 at 10:45 +0100, Koen Kooi wrote:
> > This is simply because we have no established way of receiving data
> > through the SCM for merging into trunk without direct write access.
> As
> > my other email says, I'd like to find a way of supporting that but
> its
> > probably an education issue on both sides.
> 
> And the fact that we usually have to tweak 80% if the patches we
> receive.

If you do that, can you commit the patch from the original author
literally on a branch, then apply your own changes which fix it on top
of the original patch and then merge back into the main trunk? I did an
experiment and found that this considerably eases the pain for external
contributors.

The experiment simulated a "worst case" scenario:
      * external author creates a new file
      * OE developer modifies and renames the file before committing to
        the trunk
      * external author updates the trunk and merges automatically
      * => file exists twice with different content; without renaming
        there would be a merge conflict

If external contributor and core OE developers adhere to the following
procedures, then the merge conflict is avoided. The external developer
should:
      * pull official OE monotone database
      * checkout, make changes
      * commit on a personal branch ("mtn commit -b
        personal.branch.name")
      * generate a patch (e.g. "mtn diff -r org.openembedded.dev", be
        more specific if necessary)
      * propose to merge the patch by submitting it in the OE tracker
      * continue working on the personal branch
      * follow upstream changes by propagating them ("mtn propagate
        org.openembedded.dev personal.branch.name" + "mtn update -b
        personal.branch.name")

To accept this contribution, a core OE developer should:
      * apply the original patch ("patch <foo.patch" + "mtn add <new
        files>")
      * commit on a new branch _before_ making any changes to it ("mtn
        commit -b org.openembedded.<developer>.merging")
      * make any required changes on that branch
      * commit, then propagate to org.openembedded.dev

This worked for me in the scenario above where the external developer
had not made further changes on his branch. During propagating the trunk
with patch + changes applied monotone reported that no merging was
necessary and directly made the current head part of the personal
branch. After that, updating the personal branch had all changes. I
suppose it would have worked just as well if merging had been needed
because monotone had all the required information.

One of the disadvantages is the need for another branch. I don't think
it has to be pushed into the official monotone DB, so only the developer
doing the merging needs to know about it. I should even be possible to
reuse the branch in multiple patch/commit/fix/propagate cycles by
propagating the trunk to it before applying changes.

Clearly this puts some extra work on the OE developers, but in exchange
you not only encourage external contributions, you also better document
inside monotone what the original patch was and how you modified it.

What do you think? Did I miss something?

-- 
Bye, Patrick Ohly
--  
Patrick.Ohly at gmx.de
http://www.estamos.de/