No more release schedules.

[Eric Hameleers]

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

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

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

-- 
Eric Hameleers <alien at slackware.com>
Jabber: alien at jabber.xs4all.nl