[one-users] "Official" Debian packages

[Daniel Dehennin]

Jaime Melis <jmelis at opennebula.org> writes:

>> Hmm, writing the question seems to gives my answer, it looks like the
>> cherry-picking of master commits on the one-<version> branches are the
>> reasons of the merge conflicts.
>>
>
> Yes... that's the way we usually do it: by cherry picking the commits.

Ok, I'll broke everything to rebase on master then.

> Unfortunately we don't think there's an easier way.

Personally, I prefer to use DaggyFix[1][2] over cherry-picking.

This requires to base the commits on the oldest supported release and
then merge them everywhere needed, which can be seen as a lot of work,
but not that much different from doing cherry-picking ;-)

I think DaggyFix is more GIT friendly and respect the context as explain
in an article I just found[3].

For example, here is the GIT graph to apply a foo-bar patch (issue #42):

o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-M₃ <- master
   \     \   \   \             /
    \     \   \   o-o-o-o-M₂  /    <- prod/4/master (integration branch for version 4)
     \     \   \         /   /
      \     \   \     o-o---+      <- prod/3/42-foo-bar (short living branch)
       \     \   \   /   \
        \     \   o-o-o-o-M₁       <- prod/3/master (integration branch for version 3)
         \     \
          \     o-o-o-o-o-o-o-M₀   <- prod/2/master (integration branch for version 2)
           \         \       /
            \         o-o-o-o      <- prod/2/41-fix-something
             \
              o-o-o-o-o-o          <- prod/1/master (integration branch for version 1)

in this example:

- version 1 is not supported anymore

- version 2 is supported but not concerned by #42: foo-bar

A temporary branch is created based on version 3 named prod/3/42-foo-bar and
the commits are done here.

I use do to prefix my branch names by the name of the release branch it
first apply to, it help to sort them when doing “git branch” ;-)

Then, this 42/foo-bar branch is merge back into version 3 integration
branch (commit M₁), to prepare a new release 3.X.

This 42/foo-bar branch is merge into version 4 integration branch
(commit M₂) if it apply to it like in my example.

Finally, this 42/foo-bar branch is merge into the main development
branch (commit M₃) if it apply to it like in my example.

This is based on the “successful Git branching model[4]” I extended with
the packaging branches.

I hope it will help you, it took me time to find some kind of best
practice I agree with, like “Is it better to rebase or merge?[5]”.

Regards.

Footnotes: 
[1]  by mercurial http://mercurial.selenic.com/wiki/DaggyFixes

[2]  by monotone http://wiki.monotone.ca/DaggyFixes/

[3]  https://queue.acm.org/detail.cfm?id=1595636

[4]  http://nvie.com/posts/a-successful-git-branching-model/

[5]  http://www.randyfay.com/node/91

-- 
Daniel Dehennin
Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
Fingerprint: 3E69 014E 5C23 50E8 9ED6  2AAD CC1E 9E5B 7A6F E2DF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 342 bytes
Desc: not available
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20150217/3a6cfc7f/attachment.pgp>