No more release schedules.

[Wulf C. Krueger]

(From a packager's and very, very long-term KDE user's point of view:)

> Since KDE is the community, how can we do a KDE 4.8?
[...]
> I think it's good for KDE to let each module set their freezes on their own

So you want the community to freeze? ;-) 
(Really, guys, face it: Most of us still call "KDE SC" KDE and didn't jump the 
enterprisey marketing bandwagon.)

Seriously, though, you can still publish a KDE *SC* 4.8 (or 5.0 or whatever) 
and a corresponding release schedule called exactly that.

> Then there will be a new workflow for kdelibs, with new policies about what
> to release from which branch. I just don't think one release schedule will
> fit all modules.

If they don't, KDE SC as such will either cease to exist as we know and like 
it because everyone releases when and if he wants or, as per your later 
suggestion, there will be two major releases a year and a horrible mess 
between those two dates.

> Just like kdepim could not follow the release schedule the last releases,

That was a disaster which you guys should try to avoid real hard. You 
shouldn't try to make a virtue out of that vice but work on not repeating it.

> I think it's time for more 'freedom' in this area...

You call it 'freedom', I call it an uncontrollable chaos and a mess.

> > Are you serious that you want to decouple the release of our
> > frameworks from each other? THat would create a huge mess,
> > extreme amounts of overhead, be very destructive to our 
> > community... 

This is absolutely true. Creating distro packages from such a version mix will 
become a nightmare. Not to speak of the problem that there will not be a 
common "KDE SC experience" across all distros anymore but a pretty much random 
collection of modules according to the individual release plans of both 
modules and distros. (Not to speak of us source-based distros with "rolling 
releases".)
 
> I assume Platforms will need several alpha releases to test their work and
> have different milestones, not being bound to a central schedule will be
> helpful there.

Even today, some distros have either not even started working on the 4.7 beta 
because of the comparedly small mess we're already facing today. My guess is 
that those alphas (at different milestones) won't get much testing at all 
because we, as packagers, will likely have a hard time puzzling all the pieces 
together properly - and some of us most likely won't even bother to try.

> We can set a preferred release day twice a year, which every module can
> work to if they like.

So, if they don't like to work toward it, there won't be unified KDE SC 
releases anymore? And even if there are, there will be only *two* releases a 
year? I'd consider that a *major* step beackwards.

> > Coordinate? We *create* releases and manage them.
> We can still package and release them if you like, that's independent of
> the schedules.

Uhm... No? *What* are you going to package? How are you going to make sure 
whatever you decide to package is actually going to work with the other 
modules? Of course, you can randomly pick some date, package and release 
whatever is available at that point but, from a QA point of view, this might 
not be the wisest approach to release engineering.

Best regards, Wulf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20110609/a9c0dcd2/attachment.sig