Re: Gtk+ merges

[Alexander Larsson <alexl redhat com>]

On Mon, 2009-05-25 at 10:59 -0500, Federico Mena Quintero wrote:
> > I don't think merging the stable branch ever makes sense, we don't want
> > to merge e.g. a version bump in the stable branch to the unstable. I
> > think the best approach is to commit fixes to master, then cherry-pick
> > them to the stable branch.
> 
> The problem I see with cherry-picking is that you have to look in two
> places to see if a fix appears in both branches.  If you merge from
> stable to master, you only have to see if you re-merged after the fix in
> question.
> 
> My rationale is:
> 
> 1. At some point, the stable branch is created from master ("we go into
> maintenance mode").
> 
> 2. Only fixes go into stable.  Since they are stable, they should go
> into master as well.

I don't think this is true. First of all, the fix that goes into stable
and the fix that goes into master may very well be different (i.e. a
hack for stable, new API for master). Secondly, there are various
commits to stable that should never go into master, for instance updates
to configure.in for version bumps, NEWS updates for releases, etc. Not
to mention the kind of pofile conflicts you had (the list of strings
change, causing complex pofile changes and thus conflicts).

It just sounds to me like a very complex and risky way to handle it.
Each time you want to merge a feature from the stable branch you need to
have perfect understanding of all other not-yet-merged changes on the
stable branch and how they work on stable, and this fact is completely
non-obvious from the commit that gets added ("merged stable").

Not to mention that it gets very weird when you do it this way and
everyone else doesn't, so the master history now have duplicate commits
for each fix on stable that you didn't commit.

> I think we are used to cherry-picking because there was just no other
> sane way of doing things with SVN.  Cherry-picking is easy ("get me that
> patch here"), but I think merging aids maintainability when you want to
> ensure that branches have *all* the right fixes from other branches.

I'm not at all sure you want to have all fixes from stable on master.
Furthermore, I think the idea of baking things in master and then cherry
picking to stable sounds like a generally better order than pushing the
patches to stable first. (Of course, we generally commit then
cherry-pick/merge immediately, so the amount of testing something gets
before going to stable is admitedly small.)