No more release schedules.
kevin.kofler at chello.at
Thu Jun 9 23:43:35 CEST 2011
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.
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.
More information about the release-team