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

[Thorbjørn Martsum]

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*).

>When in doubt, consult with someone more experienced.
Well, Marc gave a link to the case... :)

regards
Thorbjørn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121208/6e822a9a/attachment.html>