No more release schedules.

Modestas Vainius modax at debian.org
Fri Jun 10 02:18:03 CEST 2011


Hello,

On penktadienis 10 Birželis 2011 00:09:16 Eric Hameleers wrote:
> > 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.

What do small tarballs have to do with this disintegration? I do understand 
that you dislike small well-split tarballs but, seriously, don't blame 
everything on them. It's only a different way how tarballs are generated, it 
has nothing to do with integration or testing.

> 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.

Distros are already pretty different with monolithic tarballs. Have you tried 
various distros lately? Some distros patch or backport more, some less or 
don't at all, some use official branding, some don't etc. Distros can even 
skip entire modules if they wish. Or they can skip (and they do) parts of some 
modules, it just needs a one-line patch to the top CMakeLists.txt. Or apps can 
be thrown away post-build.

KDE might be disintegrating at community level, but being packaged in a better 
way at the source level does not have anything to do with this.

> 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.

Well, if a distro wanted to add Unity of KDE, it would. If you seriously think 
that monolithic tarballs are going stop from doing that, you're really 
mistaken.

-- 
Modestas Vainius <modax at debian.org>
-------------- 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/20110610/44b8141c/attachment.sig 


More information about the release-team mailing list