On Thu, Mar 7, 2013 at 10:58 AM, Albert Astals Cid <[email protected]> wrote:
> El Dijous, 7 de març de 2013, a les 01:48:30, David Edmundson va escriure: > > On Wed, Mar 6, 2013 at 11:49 PM, Albert Astals Cid <[email protected]> > wrote: > > > El Dimecres, 6 de març de 2013, a les 14:52:07, Vishesh Handa va > escriure: > > > > On Tue, Mar 5, 2013 at 5:13 AM, Albert Astals Cid <[email protected]> > wrote: > > > > > A few months ago we were discussing changes regarding 4.11 > > > > > > http://mail.kde.org/pipermail/release-team/2013-January/006708.html > > > > > > > > > > The changes I suggested where > > > > > *************** > > > > > 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 > > > > > > > > > > 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 > > > > > > > > I cannot say much about the beta releases, but having the 3 release > > > > candidates for 4.10 helped a LOT. Do we have any statistics to back > up > > > > > > this > > > > > > > claim that it did not help? > > > > > > Do you have statistics to claim it did? Martin reached the conclusion > that > > > "4.10 cycle significantly less bugs have been created than in the other > > > cycles" > > > http://mail.kde.org/pipermail/release-team/2013-January/006761.html > > > > That's not enough to suggest a correlation. > > I know. The same applies the other way around. > > > We do have knowledge that some > > really big bugs were found in the various releases and that they were > fixed > > before 4.10.0. RC3 was added because important things were found in the > > earlier RCs, so we know it does help quality. > > Not really, RC3 was added because people commited features very late in the > game. > > > Anyway, I won't argue further because I'm late to the party and it's not > > very productive. > > > > What I would like to do is propose that going down to 1 beta and 1 RC > isn't > > a full policy change but a trial run for 4.11 and that it should be > > re-evaluated afterwards for 4.12 once we do have some statistics and > > feedback from developers involved. > > Personally I'm against. 4 pre-releases to 2 is too big a change to risk. > I actually like you to say if you want it or not since if you read my email > I'm unsure about going down to 1 beta and 1 RC. > > Cheers, > Albert > > > > > That might be the plan already, but if so it wasn't super clear to me > > > > This is especially important if 4.12 is in fact 5.0. > > > > > > > 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 > > > > > > > > > > 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. > > > > > *************** > > > > > > > > I'm not sure I understand this point. Suppose I was committing a > simple > > > > > > fix > > > > > > > to something wrong in the code. Would I first have to file a bug for > it > > > > > > and > > > > > > > then explicitly close the bug with the commit? Or can I just add > > > > "SCHEDULE-CHECK: bugix"? > > > > > > You could simply use SCHEDULE-CHECK: bugfix > > > > > > Cheers, > > > > > > Albert > > > > > > > > I have gone through all of the mails of the thread and if i did > not do > > > > > > a > > > > > > > > mistake in the interpretations of the emails, these are the > "results" > > > > > > > > > > 1) Drop Betas to 1 > > > > > 2) Drop RCs to 1 > > > > > > > > > > Albert Astals Cid - yes > > > > > Christian Mollekopf - yes > > > > > Sebastian Kügler - yes with comments > > > > > Martin Gräßlin - No > > > > > > > > 3) Increase RC time between tag and packaging > > > > > > > > > Albert Astals Cid - yes -> Reword schedule > > > > > Sebastian Kügler - Reword schedule > > > > > Torgny Nyblom - Reword schedule > > > > > > > > > > 4) Don't release if any if the tests are failing in builds.kde.org > > > > > > > > > > Albert Astals Cid - yes > > > > > Michael Palimaka - yes > > > > > Christian Mollekopf - yes > > > > > Martin Gräßlin - yes with comments > > > > > > > > > > 5) Introduce an pre-commit check after Feature freeze > > > > > > > > > > Torgny Nyblom - yes > > > > > Christian Mollekopf - yes with comments > > > > > Albert Astals Cid - unsure > > > > > > > > > > So my reading is that we should do 3 as a reword of the schedule > and 4 > > > > > > for > > > > > > > > sure. > > > > > > > > > > I'm a bit unsure about 1, 2 and 5. Anyone has extra opinions to > share? > > > > > > I'd > > > > > > > > like to have a finalized schedule for 4.11 next week. > > > > > > > > > > Cheers, > > > > > > > > > > Albert > > > > > > > > > > _______________________________________________ > > > > > 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 > _______________________________________________ > 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
