[Development] RFC: What constitutes a "non-destabilising" bug-fix?

[Alan Alpert]

On Sat, Dec 8, 2012 at 3:30 AM, Thorbjørn Martsum <tmartsum at gmail.com> wrote:
>
>
> On Fri, Dec 7, 2012 at 4:53 PM, Thiago Macieira <thiago.macieira at intel.com>
> wrote:
>>
>> In the general sense, those are the bug fixes that have a high benefit /
>> risk
>> ratio. That is, the changes they introduce are of low risk to introduce
>> more
>> regressions and unexpected behaviour changes, while fixing some important
>> issue.
>>
>> Does it require precognition? No, it requires experience. Yes, it's
>> subjective. That's what the Spirit Fit guidelines for. All Approvers are
>> supposed to exercise their grey mass and decide whether the change is
>> right
>> and in the right branch. When in doubt, consult with someone more
>> experienced.
>>
>>
>> Going from the general case to this specific case: the Release Team has
>> the
>> right to set stricter guidelines concerning their release. We have not yet
>> created the releases branch, which is where the RCs should be coming from.
>> So
>> that team is telling us that we would like to have an even higher benefit
>> /
>> risk ratio than would be normal.
>>
>
> Hi Thiago
>
> Thanks for using some time to answer, but I am not sure the problem is
> solved now ...
>
>
>>In the general sense, those are the bug fixes that have a high benefit /
>> risk ratio.
>
> That statement is quite obvious. It does not change the vague definition,
> and there are different views on what it means.
> Now the situation is that Marc (maintainer) preferred my patch in stable,
> while Andy Shaw (approver) preferred it in dev.
>
> I (not a Qt-newbie) think it would be ok in stable, but as the patch-writer
> my opinion might not be objective.
>
> Andy does not want to block the patch from stable, and Marc (nor I) want to
> enforce it into stable. We want to do the right thing.
> This is not itself a major issue and we could call for more reviewers to
> decide or maybe even ask Lars, but it would be easier if the directions
> could be made more clear.
>
> Beside the problem is a bit worse than that. I uploaded to dev and
> considered it would be no problem to get it into stable if we wanted to do
> that (dealing with
> one problem at a time)
>
> I can however see I was wrong after reading
> http://qt-project.org/wiki/Branch-Guidelines and the ML-mail from Oswald:
>
> submit fixes to the lowest applicable branch
> (generally stable, later release for release-critical problems) and wait
> for them being forward-merged to dev by a qualified merge master.
>
> However this is an annoying regression to the Qt work flow. Before I always
> uploaded to master and
> then it could afterwards be considered if we wanted to back-port it to 4.8.
> Now, not only I - but regular
> newcomers - have to decide which level their bugfix/improvemnt should be in.
> This is not reasonable since
> even the most experienced Qt-developers will often need to see a given
> patch, before they can decide on
> if it should be in stable or dev (that is if they can agree).
>

The 'old' workflow with multiple major versions being worked on at
once was a temporary situation. dev/stable is not the same thing as
5.0/4.8. As I understand the theory features go into dev, bugfixes go
into stable, and you finally get to stop backporting your fixes to 4.8
(probably). If in doubt develop and push to stable on gerrit, the
approver can then advise whether the change should be repushed to dev
(which is very easy to do).

This thing about the non-destabilizing bug fixes is just the release
team being cautious because we don't have a release branch yet.
Theoretically I'd have thought the release branch should have started
for RC1 and then the release team would cherry-pick fixes into that
branch. But if that's not happening then we just have the same work
flow as in 4.x when there was only one master: be cautious with
commits around release time. The only reason this might be perceived
as a regression is that we actually have another branch that won't get
into the release, allowing development to continue like we had always
dreamed of.

So it seems we're currently only half-way over into our new branching
paradigm and that will be confusing until we shift fully. Unless I got
the new paradigm wrong, in which case it's confusing now ;) .

--
Alan Alpert