[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: Vishesh Handa <me () vhanda ! in>
Date: 2013-03-06 9:34:07
Message-ID: CAOPTMKB4_=E2rOBfrwRMnAgg+3=e5bHHnLwaHCmK83w8WqPOZA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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?
>
> 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"?
>
> 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@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>
--
Vishesh Handa
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On Tue, Mar 5, 2013 at 5:13 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"> 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>
It doesn't seem "to me" that having extra betas gives us much \
more quality,<br> so my suggestion is to drop Beta 2 and move Beta 1 to happen in \
Beta 2 time<br> (moving also Hard Freeze) which gives us 2 more weeks for feature<br>
development<br>
<br>
2) Drop RCs to 1<br>
Same thing, it did not feel to me as that it gave us much, drop RC2 and \
RC1<br> one week into the future<br></blockquote><div><br>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?<br> <br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>
3) Increase RC time between tag and packaging<br>
One day between tagging and release is crazy, let's have 5/6 days 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> If we have \
tests, they have to work<br> <br>
5) Introduce an pre-commit check after Feature freeze<br>
That check would look for "SCHEDULE-CHECK: bugfix" in the commit \
log and<br> reject the commit otherwise. This would fix the fact that people seem to \
be<br> commiting features and then saying "oh, but i did not read the emails \
you<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></blockquote><div><br>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"?<br> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>
I have gone through all of the mails of the thread and if i did not do a<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>
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>
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> 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>
Torgny Nyblom - yes<br>
Christian Mollekopf - yes with comments<br>
Albert Astals Cid - unsure<br>
<br>
<br>
So my reading is that we should do 3 as a reword of the schedule and 4 for<br>
sure.<br>
<br>
I'm a bit unsure about 1, 2 and 5. Anyone has extra opinions to share? \
I'd<br> like to have a finalized schedule for 4.11 next week.<br>
<br>
Cheers,<br>
Albert<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> \
</blockquote></div><br><br clear="all"><br>-- <br><span \
style="color:rgb(192,192,192)">Vishesh Handa</span><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