[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: KDE SC 4.11 Release Schedule (bis)
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2013-03-06 23:49:31
Message-ID: 1742961.vCxtShzMkx () xps
[Download RAW message or body]

El Dimecres, 6 de mar=E7 de 2013, a les 14:52:07, Vishesh Handa va escriure:
> On Tue, Mar 5, 2013 at 5:13 AM, Albert Astals Cid <aacid@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 m=
ore
> > =

> > 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 th=
is
> 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 da=
ys
> > =

> > 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 y=
ou
> > 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 f=
ix
> to something wrong in the code. Would I first have to file a bug for it a=
nd
> 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=FCgler - yes with comments
> >   Martin Gr=E4=DFlin - No
> > =

> > 3) Increase RC time between tag and packaging
> > =

> >   Albert Astals Cid - yes -> Reword schedule
> >   Sebastian K=FCgler - 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=E4=DFlin - 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@kde.org
> > https://mail.kde.org/mailman/listinfo/release-team
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
[prev in list] [next in list] [prev in thread] [next in thread]