Git repositories created and how to work with them

[Nicolai Haehnle]

Lurker here...

On Tue, May 4, 2010 at 9:21 AM, Andreas Pakulat <apaku at gmx.de> wrote:
> I've created a 4.0 branch already from master, thats our stable branch
> and should get all bugfix commits on it. We'll than have to make sure
> that its merged once a week (or more often for important fixes) into
> master so that master also gets the bugfixes. I don't want to be
> responsible alone for that, so if anybody notices no merge on sunday
> evening if there's been commits to 4.0 branch in the week, please just
> do the merge.

For what it's worth, there has just been a discussion on the Mesa3d
mailing list about getting rid of exactly this process. At least from
my understanding, the main problems with this process are:

1) Developers don't care about stable trees, and policy decisions
cannot change that.

Developers work in master, and it's a hassle for them to even know
whether a certain bug they run into affects the stable branch or not
(after all, the feature that is affected by the bug might not even be
in the stable branch; it's easy to forget such details two months
after a release). At least when the developers are volunteers hacking
on the project in their spare time, you just cannot force them to care
enough, so you will have to cherry-pick anyway.

People who care about stable trees are often disjoint from developers;
they're closer to distribution release processes, for example.

2) Merges from stable to master cause conflicts.

When stable and master have diverged in an area, it regularly happens
that a bugfix in stable does not cleanly merge into master. If the
person who does the stable->master merge is not the same as the person
who committed the bugfix, then the merger does not know what the right
way to fix the merge is. This has caused major frustration on several
occasions.

All in all, in a commit-to-stable policy, it appears better to have
the committer merge to master immediately, because then they're the
one to fix any merge conflicts. (Yes, this causes many merge commits;
tough luck.)

3) Bug fixes cause regressions.

It happens regularly that a well-meant bug fix in stable causes
regressions, and so stable actually becomes less stable, because bug
fixes aren't tested in master first.

All of these things may or may not apply to KDevelop (for example,
point (3) is probably worse for Mesa; at least KDevelop doesn't have
to worry about regressions affecting only certain hardware models),
but do keep them in mind, especially if you're already used to the
cherry-picking / backporting way of working.

Just another perspective, that you're obviously free to ignore.

cu,
Nicolai