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

[Knoll Lars]

On Jan 13, 2013, at 12:39 PM, Olivier Goffart <olivier at woboq.com> wrote:

> On Friday 11 January 2013 07:40:39 Thiago Macieira wrote:
>> On sexta-feira, 11 de janeiro de 2013 15.21.43, Olivier Goffart wrote:
>>> Go to stable:
>>>  a. Fixes to regressions against a previous "recent" version of Qt. (less
>>>      than 2 or 3 years old)
>>>  b. Fixes in new feature introduced in the most recent minor version.
>>>  c. Critical fixes (P1/P0): security, crashes or data corruption.
>>>  d. Compilation fixes or adaptations required for different version of
>>>      the compilers or upstream libraries.
>>> 
>>> Everything else go to dev.
>> 
>> I agree with almost all: I'd like to relax "c" to include Important (P2)
>> fixes, subject to the approvers' decision. Those should happen most
>> commonly in the first one or two patch releases (.0 and .1).
> 
> Everything is already subject to approvers' decision.  So specifying it is 
> redundant.
> 
> I think anyway every rules rules should tollerate exceptions. In certain cases 
> approvers will break those rules for good reason.
> Example: a one-line feature that is critical for an important application may 
> get in in a patch release.
> 
> The reason why I would avoid non-regressions P2 fixes in the stable branch is 
> that they are more risky than the others one.
> 
> A new minor version gets much more QA that a patch release. (there are beta 
> release).  Also, everybody tollerates a x.y.0 to have bug, but it is really 
> bad if we introduce more bugs in patch release.
> And I beleive one good way to avoid regressions in patch releases is to limit 
> the amount of risky changes that goes it.
> 
> If we tollerates P2, i'm afraid every P2 goes in, and that's most of the fixes.
> 
> Do you still think the wording should include P2?

We might want to tighten the rules as Qt 5 gets more mature and aim for only P0/P1. Right now, I believe fixes to P2's are still a good idea as they will improve the quality of the releases (with some risk of getting regressions).

So I'm for the above list with point c being:

c. Critical fixes (P1/P0): security, crashes or data corruption. P2 fixes when there is a good reason/need.

Cheers,
Lars


> 
> -- 
> Olivier
> 
> Woboq - Qt services and support - http://woboq.com
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development