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

[Thiago Macieira]

On sexta-feira, 7 de dezembro de 2012 10.41.53, Marc Mutz wrote:
> The only indication for what is acceptable for submission to 'stable' is
> the  text boxes in the graphics under point 2 of section Permanent
> Regime: "non-destabilising bugfixes".
> 
> For me, by definition, any bug-fix targets to be stablising; to distinguish 
> stablising and destabilising bugfixes thus requires the art of
> precognition, which I sadly lack...
> 
> On IRC, we see opinions ranging from 'regression-only fixes' to 'basically
> any  bug fix, as long as it doesn't violate the BC and string freeze that
> 'stable' is under'.
> 
> So can we get a more concrete indication of what it acceptable in 'stable', 
> please?

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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121207/5618e78f/attachment.sig>