El Divendres, 18 de gener de 2013, a les 03:13:05, Christian Mollekopf va escriure: > On Tuesday 15 January 2013 23.27:53 Albert Astals Cid wrote: > > El Dimarts, 15 de gener de 2013, a les 16:30:50, Allen Winter va escriure: > > > > I'd like to propose some changes for 4.11, i'd like everyone to comment > > > > 1) Drop Betas to 1 > > > > It doesn't seem "to me" that having extra betas gives us much more > > quality, > > > > so my suggestion is to drop Beta 2 and move Beta 1 to happen in Beta 2 > > time > > (moving also Hard Freeze) which gives us 2 more weeks for feature > > development > > +1 > > > 2) Drop RCs to 1 > > > > Same thing, it did not feel to me as that it gave us much, drop RC2 and > > RC1 > > > > one week into the future > > +1 > > > 3) Increase RC time between tag and packaging > > > > One day between tagging and release is crazy, let's have 5/6 days as we > > > > have for the other releases > > > > 4) Don't release if any if the tests are failing in builds.kde.org > > > > If we have tests, they have to work > > I think that would be a very good idea. That would also give some level of > confidence that tests actually work, as some of the tests are not entirely > trivial to run (with dedicated akonadi/nepomuk instance etc.), and if you're > not even sure that they actually work... > > > 5) Introduce an pre-commit check after Feature freeze > > > > That check would look for "SCHEDULE-CHECK: bugfix" in the commit log and > > > > reject the commit otherwise. This would fix the fact that people seem to > > be > > commiting features and then saying "oh, but i did not read the emails you > > send every month saying we are in a feature freeze so i did not know I > > couldn't do this", this way at least they would be forced to say their > > stuff is a bugfix. > > If the feature freeze is short enough (see 1), it might be even nicer if a > corresponding bugreport has to exist, which could help QA people to see > what's happening and track QA efforts. As always, there has to be a way to > circumvent this e.g. by a keyword in the commit message. If it just becomes > a no-brainer to always add a keyword to the commit it probably won't help a > lot though.
Yes Fabio D'Urso worked for fun on some implementation of this and he had a SCHEDULE-CHECK: force and lots of more bells & whistles i did not add here since i regarded them as implementation detail. I think that what is worth discussing is if the idea of forcing people to say "yes this is a bugfix" makes sense or not. Cheers, Albert > > Cheers, > Christian > > _______________________________________________ > release-team mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/release-team _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
