On Friday 25. January 2013 09.12.09 Knoll Lars wrote: > On Jan 13, 2013, at 12:39 PM, Olivier Goffart <oliv...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
