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

[Marc Mutz]

Hi Andy,

On Monday December 10 2012, Shaw Andy wrote:
> > Ok, trying to summarise, I understand it this way:
> >
> > 1. release-critical fixes are submitted and merged to 'stable' now,
> >    'release' later, when it exists.
> >    No-brainer fixes are also welcome.
> > 2. bug-fixes that don't violate string or BC freezes are submitted,
> >    but NOT merged, against stable.
> >    They will be merged once RC2 is tagged and 'release' is branched off.
> >    Maintainers and other reviewers can redirect a fix to 'dev' instead,
> >    but all fixes that don't require string or BiC changes should
> > initially be submitted to 'stable'.
> >    [Personally, I'd add that if a fix goes to 'dev' instead of 'stable',
> >    then the commit message should say why.]
>
> [snip]
>
> I don't agree that all bug fixes should go into stable, judgement should
> certainly be made, but we can't just put all bug fixes blindly into stable
> otherwise it will probably end up as being far from stable.  There are
> times when it would be better for a bug fix to go into dev instead of
> stable because it may give a much too obvious behavior change for example.

I was suggesting that bug-fixes _initially_ be submitted for stable (blindly, 
if you will) and that review decides whether to redirect them to dev instead.

So I wasn't suggesting to "just put all bug fixes blindly into stable". I want 
to avoid them going blindly to dev, though, esp. without the commit message 
explaining why.

I agree with you otherwise.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions