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

[Jedrzej Nowacki]

On Friday 25. January 2013 09.12.09 Knoll Lars wrote:
> 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

e. Autotests extensions and new tests should go to stable if possible. It 
simplify merging process.

Cheers,
  Jędrek