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
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
