No more release schedules.
alien at slackware.com
Fri Jun 10 10:49:47 CEST 2011
On Fri, 10 Jun 2011, Modestas Vainius wrote:
> On penktadienis 10 Bir?elis 2011 00:09:16 Eric Hameleers wrote:
> 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.
Forget about my earlier dislike of splitting into smaller tarballs for
a moment - that issue has nothing to do with this dicscussion at hand.
If KDE release team decides to stop releasing monolithic tarballs, I
will find a way to cope with it - there is more work involved but
essentially the build and packaging process will only have to change
once. For as long as the release process stays co-ordinated and all
sources are released in unison, so that I know what I am packaging.
>> 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.
Certainly, distros apply patches, backports and branding but the issue
is that when someone states "I am using KDE SC 4.6.3" you largely know
what he is using. If the user has an issue, this makes the
troubleshooting more deterministic.
> 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.
>> 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
Again, monolithic tarballs or not, this is not the topic. Coordinating
the release process for all the individual submodules is what is going
to make or break KDE's acceptance. Do I have to remind you of the
consequences of the X.Org release process? For the past years, ever
since X.Org went modular, there has not been a single distro that was
able to deliver a consistently working X desktop. Why do you think
Wayland gets so much attention? There is total chaos in the release
process for X.Org, individual submodule maintainers decide largely
among themselves what dependencies and what software versions they
require for their releases. As a result, packaging X.Org is not a
pleasant and reqarding experience. With the proposal under discussion,
I predict that KDE is going to foot itself firmly on the same
Give me the chance to have a deterministic build process and I will
cheer. I am not aiming at "let's ruffle through the KDE ftp server
directories, grab this and that software update and hope for a 95%
working desktop". I want a _working_ desktop.
So forget about monolithic tarballs please. It is clouding the issue.
Eric Hameleers <alien at slackware.com>
Jabber: alien at jabber.xs4all.nl
More information about the release-team