No more release schedules.

Jorge Manuel B. S. Vicetto jmbsvicetto at
Fri Jun 10 04:18:37 CEST 2011

Hash: SHA1

On 09-06-2011 21:09, Eric Hameleers wrote:
> On Thu, 9 Jun 2011, Andreas K. Huettel wrote:
>> Dear KDE upstream,
>>>> 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 puzzles me as I know how
>>>> much you
>>>> love KDE.
>>> What does my love for KDE have to do with it? I think it's good for KDE to
>>> let each module set their freezes on their own, depending on which work
>>> flow they will adapt. If we decide it early the module maintainers have
>>> time enough to get used to creating the schedule.
>> Basically this is nothing but a dissolution of the KDE project as a whole.
>> Sure, we'll end up with a lot of projects using and enhancing kdelibs (or
>> whatever becomes of that), but there will be no coherence anymore.
>>> We can set a preferred release day twice a year, which every module can
>>> work to if they like.
>>> We can still package and release them if you like, that's independent of
>>> the schedules.
>> That both makes no sense. Suggestion 1 fails completely with the "if they
>> like" part, since we all know already how much pain the "out of sync kdepim"
>> caused. Suggestion 2 fails with the "independent of the schedules" part,
>> because you can't release somthing that is not stabilized and tested.
>> Please try to get some sense back...
>> Cheers,
>> Andreas
> 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.
> Eric


I agree with Andreas and your sentiment about this issue.
However, please don't mix the split of the tarballs and repositories
with the decision to stop the release schedules. As others have already
argued, KDE can keep release schedules, create spit tarballs from the
individual repositories and even maintain global cmake files to recreate
a complete module from the individual tarballs.

I'm waiting for some "clarifications" from Tom and reactions from the
other release team members about this proposal to drop the release
As a packager for Gentoo, I think the schedule module used for the last
years (with the exception of what happened to the kdepim module) is a
good thing and should not be thrown out. The possibility of having
different parts of the KDE environment being released independently and
or a complete disconnect in releases between different parts of the
project sounds like a terrible headache for packagers. Also, as others
have pointed out, I fail to see how there could be any QA work for the
tarballs and how could you get enough attention from the packagers to be
sure there is enough and sufficient testing of them.
One of the worst points in recent KDE history is the QA of the tarballs.
Please work hard to improve it and defer from doing anything that
compromises it even further.

- -- 

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the release-team mailing list