No more release schedules.

[Kevin Kofler]

On Thursday 09 June 2011, Eric Hameleers wrote:
> Andreas, how I agree!
> 
> This now, is _exactly_ what I was afraid for when I voiced my concern
> about the break-up of this relatively small collection of coherent
> source tarballs we are used to work with, into a fragmented and
> potentially disconnected set of individual small (project-oriented)
> source tarballs. This would mean, KDE as an integrated software
> collection is dissolving into a loose collection of software perhaps
> not even branded "KDE" anymore.
> 
> Notwithstanding the "frameworks" concept, which sounds appealing, you
> should focus on keeping the ecosystem together. Otherwise there will
> not be a "KDE SC" soon, but instead "KDE for Slackware, KDE for
> Fedora, KDE for Arch, KDE for Windows, KDE for Solaris ..." and every
> version will be unpredictably different from the others. This
> unpredictability kills the killer concept: that KDE transcends
> operating systems. I predict that it will end up like GNOME: one
> distro adds Gnome Shell, the next adds Unity, and yet another decides
> to stick to a forward-ported old version of the desktop manager. This
> surely is not what KDE (and its users!) deserve.

+1

My main concern with disparate releases would be that it would be impossible 
to test all the possible combinations properly. Every distribution would end 
up with its own combination of versions, with the potential for 
incompatibilities nobody else can reproduce. We're already seeing enough of 
those with libraries further down the stack which KDE (the project) has no 
direct control on, and we've had a couple with the separate kdepim releases 
too. Having KDE's own packages also released in an uncoordinated fashion would 
increase the amount of problems by a lot (e.g., in my experience, trying to 
use an older kdebase-workspace with a newer kdelibs would routinely just 
crash, even though kdelibs is supposed to be backwards-compatible; we've 
regularly had Rawhide broken by that if we didn't manage to build kdebase-
workspace quickly enough for whatever reason). Please let those separate 
kdepim releases be the exception (and get kdepim back in sync with the rest of 
the software compilation for 4.7), not the rule.

Another issue is that it would really swamp most distribution's KDE software 
packaging teams to have to package a new release of package XYZ every day.

Yes, freezes can be a problem getting features to our users quickly. But just 
letting every small module pick its own schedule surely cannot be the 
solution. (My personal suggestion would actually be to do relaxed freezes as 
in the 3.5 branch. Then let the module maintainer decide what is stable for a 
point release and what not, but not proclaim a major release at a random point 
in time. But that's just another suggestion thrown into the mix.)

I realize that this is ultimately the release team's decision, but please do 
listen to packagers' concerns.

        Kevin Kofler