KDE SC 4.11 Release Schedule (bis)

[David Edmundson]

On Wed, Mar 6, 2013 at 11:49 PM, Albert Astals Cid <aacid at kde.org> 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 <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


That's not enough to suggest a correlation. 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.

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.

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
> > > release-team at kde.org
> > > https://mail.kde.org/mailman/listinfo/release-team
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20130307/1cb03469/attachment.html>