KDE SC 4.11 Release Schedule (bis)

[Vishesh Handa]

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?


>
> 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 at kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>



-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20130306/af7d6e23/attachment.html>