No more release schedules.
Wulf C. Krueger
philantrop at exherbo.org
Thu Jun 9 21:22:44 CEST 2011
(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
> 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
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20110609/a9c0dcd2/attachment.sig
More information about the release-team