KDE SC 4.11 Release Schedule (bis)

[Albert Astals Cid]

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 <aacid at kde.org> 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

> 
> > 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
> > release-team at kde.org
> > https://mail.kde.org/mailman/listinfo/release-team