[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-07 10:58:23
Message-ID: 2277831.qX9qihoqWv () xps
[Download RAW message or body]

El Dijous, 7 de mar=E7 de 2013, a les 01:48:30, David Edmundson va escriure:
> On Wed, Mar 6, 2013 at 11:49 PM, Albert Astals Cid <aacid@kde.org> wrote:
> > El Dimecres, 6 de mar=E7 de 2013, a les 14:52:07, Vishesh Handa va escr=
iure:
> > > On Tue, Mar 5, 2013 at 5:13 AM, Albert Astals Cid <aacid@kde.org> wro=
te:
> > > > 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 mu=
ch
> > =

> > more
> > =

> > > > quality,
> > > > so my suggestion is to drop Beta 2 and move Beta 1 to happen in Bet=
a 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 t=
hat
> > "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 fix=
ed
> 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.

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 se=
em
> > =

> > to
> > =

> > > > be
> > > > commiting features and then saying "oh, but i did not read the emai=
ls
> > =

> > you
> > =

> > > > send every month saying we are in a feature freeze so i did not kno=
w I
> > > > couldn't do this", this way at least they would be forced to say th=
eir
> > > > stuff is a bugfix.
> > > > ***************
> > > =

> > > I'm not sure I understand this point. Suppose I was committing a simp=
le
> > =

> > 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 "result=
s"
> > > > =

> > > > 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 an=
d 4
> > =

> > for
> > =

> > > > sure.
> > > > =

> > > > I'm a bit unsure about 1, 2 and 5. Anyone has extra opinions to sha=
re?
> > =

> > 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
_______________________________________________
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]