Hi,
We should finish this discussion and document the conclusion in
http://qt-project.org/wiki/Branch-Guidelines
...
Marc Mutz 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]
On Monday December 10 2012, Shaw Andy replied:
> > 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.
On Monday 10 December 2012 12:07:21 Marc Mutz replied:
> 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.
One problem is that re-targeting a branch with gerrit is not working. so you
need to re-submit, which is a small annoyance.
Even if we do it like that we still need criterion for the reviewer to decide.
And if those criterion are on the wiki, the contributor can just apply the
criteria them self.
And what are those criteria? When does a patch goes to dev or to stable?
I suggest this:
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.
The reason to limit to regression fixes is that if one could live few releases
with a given bug, then he can still wait another 6 months for the bug fixe.
That way we minimize the risks of introducing new subtle bugs in patch
release.
Then there is the question: What can go into Qt 4.8?
Normaly, the criterias for Qt 4.8 should be the same as for the stable branch.
For example, to me, small bugs like QTBUG-20403 should go to dev, and not to
stable or 4.8
It would be nice to come to an agreement and write the policy on the wiki.
Regards.
--
Olivier
Woboq - Qt services and support - http://woboq.com
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
