Merge or Cherry-Pick?

[Dawit A]

On Wed, Feb 2, 2011 at 6:13 PM, Andreas Hartmetz <ahartmetz at gmail.com> wrote:
> On Wednesday 02 February 2011 21:15:31 Aaron J. Seigo wrote:
>> On Wednesday, February 2, 2011, Thiago Macieira wrote:
>> > I still think the current procedure is wrong. You're not testing the
>> > stable release, there's no guarantee that you're solving the problem at
>> > all, or worse, that you're not making it worse.
>>
>> and, imho, the stable branch is the more important thing to test: if it
>> goes wrong in master due to a bad or unecessary merge from stable, you
>> usually have months to notice and fix it. certain you or your teammates
>> that also track master will notice it faster than if it sits in the stable
>> branch where primary devel isn't happening anymore. with our monthly x.y.z
>> releases, you have at most a few weeks with fewer people tracking the
>> stable branch to catch a bad merge from master.
>>
>> so, again at least imho, the risk is higher when backporting compared to
>> forward porting.
>>
>> and finally we have a tool that makes it reasonably painless to do it. :)
>
> I have two reasons to test in master:
> - I run master myself all the time.
> - If a fix really is dangerous I don't want it to appear in a bugfix release "by
> accident".
>
> If nobody was running master who'd make sure its quality was even remotely
> decent? Somehow I don't buy that we should all be testing the latest stable
> branch while developing against master. Switching environments all the time is
> a major hassle and not as effective at finding and making people care about
> bugs in master.

I also do not understand this particular flip flop to a process that
was established a long long time ago. A stable branch in KDE
historically has been treated with much much more care than throwing a
non-trivial bug fix right into it first. To me the main concern is the
fact that the bug fix release that come out every month or so after a
major release are tagged off of these stable branches.

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.

BTW, I am not simply putting up hypothetical scenarios here. What I
described above has happened to me personally on more than once
occasion. I fixed a trivial bug which ended up exposing a long
standing regression elsewhere. Thankfully for the most part the
regressions were caught before the fix was backported into the stable
branch. Anyhow, I still do not see why things should first go into the
stable branch except that is a more appropriate way of
merging/tracking code in git ??

Regrads,
Dawit A.