Merge or Cherry-Pick?

Andreas Hartmetz ahartmetz at gmail.com
Thu Feb 3 16:06:37 GMT 2011


On Thursday 03 February 2011 08:57:00 Johannes Sixt wrote:
> Am 2/3/2011 6:10, schrieb Dawit A:
> > What happens if I tested a bug fix and wanted it to push it upstream
> > so that it can receive even wider testing, but it just so happens the
> > time to tag the next bug fix release is right around the corner ? The
> > original intent is to at least leave the bug fix in the trunk for
> > several days to see if it causes any unforeseen regression. It is an
> > impossible task for any developer, specially one working on the
> > plumbing libraries, to test every possible combination or use case. If
> > the push is done into a stable branch, then there is a real
> > possibility that users are going to get exposed to unintended
> > regressions.
> 
> I'll assume you meant to say "push is done into a stable branch *too
> early*..." (otherwise, the last sentence in this paragraph is incompatible
> with the first part of the paragraph).
> 
> You do it this way:
> 
> 1. You fork off a topic branch from stable, and place your fix there.
> 
> 2. Compile-test the fix. (Bonus points, if you can test the fix in action
> with the stable version.)
> 
> 3. Merge that topic into master. Compile and test.
> 
> 4. Publish the merge. Let it cook for a week in master.
> 
> 5. Looks OK? Good. Merge the topic into the stable branch as well. (The
> stable branch might have progressed in the past week, hence, you don't
> necessarily fast-forward, but get a real merge.)
> 
> 6. Merge stable into master and publish both.
> 
> However, if you cannot test your fix with the stable version yourself, you
> should ask someone to do Step 5, additionally Step 5b "test with stable
> version", and Step 6 for you.
> 
This seems to be, except for the origin of the merge into stable which is 
irrelevant to the actual code in the repository, what Dawit and I want.
AFAIU simple bug fixes like null pointer checks go into stable first and then 
immediately into master with that approach, as suggested earlier in this 
thread.
As long as I can test fixes in master in some way I'm (for now) fine with trying 
any approach - it will probably work about equally well for everyone, so if it 
won't work for me it won't work for others and we can think again.




More information about the kde-core-devel mailing list