[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: David Edmundson <david () davidedmundson ! co ! uk>
Date: 2013-03-07 12:51:48
Message-ID: CAGeFrHC3JVqsyyyM6YAVW0rpGWXWNT9F27M3CVwou-=RJVcmtw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Mar 7, 2013 at 10:58 AM, Albert Astals Cid <aacid@kde.org> wrote:
> El Dijous, 7 de mar=E7 de 2013, a les 01:48:30, David Edmundson va escriu=
re:
> > 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
> 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
> > >
> > > 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 oth=
er
> > > 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 t=
he
> game.
>
> > Anyway, I won't argue further because I'm late to the party and it's no=
t
> > 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 ema=
il
> 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.or=
g
> > > > >
> > > > > 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 fo=
r
> 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=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.or=
g
> > > > >
> > > > > 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
> _______________________________________________
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On Thu, Mar 7, 2013 at 10:58 AM, Albert Astals Cid \
<span dir="ltr"><<a href="mailto:aacid@kde.org" \
target="_blank">aacid@kde.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> El Dijous, 7 de març de 2013, a les 01:48:30, David \
Edmundson va escriure:<br> <div><div class="h5">> On Wed, Mar 6, 2013 at 11:49 PM, \
Albert Astals Cid <<a href="mailto:aacid@kde.org">aacid@kde.org</a>> wrote:<br> \
> > El Dimecres, 6 de març de 2013, a les 14:52:07, Vishesh Handa va \
escriure:<br> > > > On Tue, Mar 5, 2013 at 5:13 AM, Albert Astals Cid <<a \
href="mailto:aacid@kde.org">aacid@kde.org</a>> wrote:<br> > > > > A \
few months ago we were discussing changes regarding 4.11<br> > > > > <a \
href="http://mail.kde.org/pipermail/release-team/2013-January/006708.html" \
target="_blank">http://mail.kde.org/pipermail/release-team/2013-January/006708.html</a><br>
> > > ><br>
> > > > The changes I suggested where<br>
> > > > ***************<br>
> > > > 1) Drop Betas to 1<br>
> > > ><br>
> > > > It doesn't seem "to me" that having extra \
betas gives us much<br> > ><br>
> > more<br>
> ><br>
> > > > quality,<br>
> > > > so my suggestion is to drop Beta 2 and move Beta 1 to happen in \
Beta 2<br> > > > > time<br>
> > > > (moving also Hard Freeze) which gives us 2 more weeks for \
feature<br> > > > > development<br>
> > > ><br>
> > > > 2) Drop RCs to 1<br>
> > > ><br>
> > > > Same thing, it did not feel to me as that it gave us \
much,<br> > > > > drop<br>
> > > ><br>
> > > > RC2 and RC1<br>
> > > > one week into the future<br>
> > ><br>
> > > I cannot say much about the beta releases, but having the 3 \
release<br> > > > candidates for 4.10 helped a LOT. Do we have any \
statistics to back up<br> > ><br>
> > this<br>
> ><br>
> > > claim that it did not help?<br>
> ><br>
> > Do you have statistics to claim it did? Martin reached the conclusion \
that<br> > > "4.10 cycle significantly less bugs have been created than in \
the other<br> > > cycles"<br>
> > <a href="http://mail.kde.org/pipermail/release-team/2013-January/006761.html" \
target="_blank">http://mail.kde.org/pipermail/release-team/2013-January/006761.html</a><br>
><br>
> That's not enough to suggest a correlation.<br>
<br>
</div></div>I know. The same applies the other way around.<br>
<div class="im"><br>
> We do have knowledge that some<br>
> really big bugs were found in the various releases and that they were fixed<br>
> before 4.10.0. RC3 was added because important things were found in the<br>
> earlier RCs, so we know it does help quality.<br>
<br>
</div>Not really, RC3 was added because people commited features very late in the<br>
game.<br>
<div class="im"><br>
> Anyway, I won't argue further because I'm late to the party and it's \
not<br> > very productive.<br>
><br>
> What I would like to do is propose that going down to 1 beta and 1 RC \
isn't<br> > a full policy change but a trial run for 4.11 and that it should \
be<br> > re-evaluated afterwards for 4.12 once we do have some statistics and<br>
> feedback from developers involved.<br>
<br></div></blockquote><div>Personally I'm against. 4 pre-releases to 2 is too \
big a change to risk. </div><div> </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div \
class="im"> </div>I actually like you to say if you want it or not since if you read \
my email<br> I'm unsure about going down to 1 beta and 1 RC.<br>
<br>
Cheers,<br>
Albert<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> That might be the plan already, but if so it wasn't super clear to me<br>
><br>
> This is especially important if 4.12 is in fact 5.0.<br>
><br>
> > > > 3) Increase RC time between tag and packaging<br>
> > > ><br>
> > > > One day between tagging and release is crazy, let's \
have 5/6<br> > ><br>
> > days<br>
> ><br>
> > > > as we<br>
> > > > have for the other releases<br>
> > > ><br>
> > > > 4) Don't release if any if the tests are failing in <a \
href="http://builds.kde.org" target="_blank">builds.kde.org</a><br> > > > \
><br> > > > > If we have tests, they have to work<br>
> > > ><br>
> > > > 5) Introduce an pre-commit check after Feature freeze<br>
> > > ><br>
> > > > That check would look for "SCHEDULE-CHECK: \
bugfix" in the<br> > ><br>
> > commit<br>
> ><br>
> > > > log and<br>
> > > > reject the commit otherwise. This would fix the fact that people \
seem<br> > ><br>
> > to<br>
> ><br>
> > > > be<br>
> > > > commiting features and then saying "oh, but i did not read \
the emails<br> > ><br>
> > you<br>
> ><br>
> > > > send every month saying we are in a feature freeze so i did not \
know I<br> > > > > couldn't do this", this way at least they \
would be forced to say their<br> > > > > stuff is a bugfix.<br>
> > > > ***************<br>
> > ><br>
> > > I'm not sure I understand this point. Suppose I was committing a \
simple<br> > ><br>
> > fix<br>
> ><br>
> > > to something wrong in the code. Would I first have to file a bug for \
it<br> > ><br>
> > and<br>
> ><br>
> > > then explicitly close the bug with the commit? Or can I just add<br>
> > > "SCHEDULE-CHECK: bugix"?<br>
> ><br>
> > You could simply use SCHEDULE-CHECK: bugfix<br>
> ><br>
> > Cheers,<br>
> ><br>
> > Albert<br>
> ><br>
> > > > I have gone through all of the mails of the thread and if i did \
not do<br> > ><br>
> > a<br>
> ><br>
> > > > mistake in the interpretations of the emails, these are the \
"results"<br> > > > ><br>
> > > > 1) Drop Betas to 1<br>
> > > > 2) Drop RCs to 1<br>
> > > ><br>
> > > > Albert Astals Cid - yes<br>
> > > > Christian Mollekopf - yes<br>
> > > > Sebastian Kügler - yes with comments<br>
> > > > Martin Gräßlin - No<br>
> > ><br>
> > > 3) Increase RC time between tag and packaging<br>
> > ><br>
> > > > Albert Astals Cid - yes -> Reword schedule<br>
> > > > Sebastian Kügler - Reword schedule<br>
> > > > Torgny Nyblom - Reword schedule<br>
> > > ><br>
> > > > 4) Don't release if any if the tests are failing in <a \
href="http://builds.kde.org" target="_blank">builds.kde.org</a><br> > > > \
><br> > > > > Albert Astals Cid - yes<br>
> > > > Michael Palimaka - yes<br>
> > > > Christian Mollekopf - yes<br>
> > > > Martin Gräßlin - yes with comments<br>
> > > ><br>
> > > > 5) Introduce an pre-commit check after Feature freeze<br>
> > > ><br>
> > > > Torgny Nyblom - yes<br>
> > > > Christian Mollekopf - yes with comments<br>
> > > > Albert Astals Cid - unsure<br>
> > > ><br>
> > > > So my reading is that we should do 3 as a reword of the schedule \
and 4<br> > ><br>
> > for<br>
> ><br>
> > > > sure.<br>
> > > ><br>
> > > > I'm a bit unsure about 1, 2 and 5. Anyone has extra opinions \
to share?<br> > ><br>
> > I'd<br>
> ><br>
> > > > like to have a finalized schedule for 4.11 next week.<br>
> > > ><br>
> > > > Cheers,<br>
> > > ><br>
> > > > Albert<br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > release-team mailing list<br>
> > > > <a \
href="mailto:release-team@kde.org">release-team@kde.org</a><br> > > > > \
<a href="https://mail.kde.org/mailman/listinfo/release-team" \
target="_blank">https://mail.kde.org/mailman/listinfo/release-team</a><br> > \
><br> > > _______________________________________________<br>
> > release-team mailing list<br>
> > <a href="mailto:release-team@kde.org">release-team@kde.org</a><br>
> > <a href="https://mail.kde.org/mailman/listinfo/release-team" \
target="_blank">https://mail.kde.org/mailman/listinfo/release-team</a><br> \
_______________________________________________<br> release-team mailing list<br>
<a href="mailto:release-team@kde.org">release-team@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/release-team" \
target="_blank">https://mail.kde.org/mailman/listinfo/release-team</a><br> \
</div></div></blockquote></div><br>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic