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.m...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development