No more release schedules.
toma at kde.org
Thu Jun 9 22:54:34 CEST 2011
The release-team mailinglist is for release coordination, reaching consensus and then announce the outcome on the appropiate lists. I think I started a valid discussion, which can be discussed maturely inside the release-team, it was not meant to be passed to a wider audience.
You have now included kde-devel and kde-packager which was not intended. If the outcome is that it was a bad suggestion that's fine, it won't happen. But you approaching those lists is very premature and harms this discussion very much.
----- Original Message -----
> would appreciate it if you all there
> would just stick to KDE, because that is what everyone uses. Nothing
Not on-topic for this list at all, nor relevant for this thread...
> Basically this is nothing but a dissolution of the KDE project as a
Really, read my mails carefully. My plan is to facilitate a trend that is going on for a bit now, which i see accelerated by the platform 10 outcome.
> Sure, we'll end up with a lot of projects using and enhancing kdelibs
> whatever becomes of that), but there will be no coherence anymore.
That's a very limited view. I think it's fine that modules have different scopes at different points in time, with different freeze and work flow requirements. Ignoring that would do KDE harm.
> That both makes no sense. Suggestion 1 fails completely with the "if
> like" part, since we all know already how much pain the "out of sync
Yes, so facilitate this mechanism better. Now we let Allen do the pim releases basically on his own. He had to do all the hard work of tarballing, dealing with translations etc. Why don't we setup the r-t as a team which can facilitate the release whenever the module maintainer deams it needed. Of course based on a proper schedule.
> Suggestion 2 fails with the "independent of the schedules"
> because you can't release somthing that is not stabilized and tested.
Did I write anywhere that we would tarball some random branch at some random time? That's not the plan. Let the module maintainer set their own freezes, make their own schedule.
More information about the release-team