KDE SC 4.11 Release Schedule

[Torgny Nyblom]

On , Albert Astals Cid wrote:
> El Dimarts, 15 de gener de 2013, a les 16:30:50, Allen Winter va 
> escriure:
>> Howdy,
>>
>> A proposed KDE SC 4.11 Release schedule is now available at
>> http://techbase.kde.org/Schedules/KDE4/4.11_Release_Schedule
>>
>> (created using toma's really useful releaseschedule program)
>>
>> Please review and report back any obvious problems, for example
>> conflicts with conferences (i.e. Akademy).
>
> I'd like to propose some changes for 4.11, i'd like everyone to 
> comment

Not sure what dates was supposed to be used if we hadn't released a RC3 
for 4.10 but it would be good to squeeze the schedule to get back to 
those "usual" dates for the final releases as it seemed that the distros 
were dependent on that.

> 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
>
> 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 like the general idea but dislike the name, but yet I cannot come up 
with a better one :)

/Regards
Torgny