modular kdelibs: packagers' view

[Eric Hameleers]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 5 Jun 2011, Sebastian Kügler wrote:

> Hi all,
>
> I'm writing this email from the Platform11 sprint in Randa, and I'd like to
> collect input how we can get the different needs of developers and packagers
> together.
>
> Let me quickly outline the situation. There has been a trend and desire to
> ship kdelibs (and other parts of our development platform, I'm just writing
> kdelibs here for convenience) as separate libraries, the reasons for this are:
>
> * can be individually consumed by 3rd party developers, no either or decision
>   for kdelibs, helps 3rd party adoption
> * kdelibs' purpose is not anymore just desktop, mobile use cases become more
>   important, more modularity helps to create leaner systems
>
> If we end up doing this, it has two important ramifications:
>
> * More individual packages, might create extra work for packagers, depending
>   on their tools
> * Change in package's structures
>
> While the consequences for developers can be kept rather low, it *will* mean
> some restructuring of existing packages.
>
> I see a couple of things we can do here:
>
> * Provide "traditional" tarballs, leading to relatively little disruption,
>   but means duplication as we provide different sets of tarballs that
>   overlap, might be more confusing than worth it

I would say that this is the cleanest solution. For me, because it 
allows to build the same coherent set of packages we use to build in 
Slackware ("you get it all"). For other packagers who stepped up to 
indicate that they do split into smaller sub-packages but work from 
monolithic source tarballs.

An important advantage to providing "monolithic" tarballs is the 
reassurance (to us packagers) that what we get is a set of software 
sources that "belongs" together. What do I mean with that (and please 
shoot holes in it if my view is wrong): at this moment the set of 
4.6.80 tarballs are all carrying that version number. That indicates 
that this collection too, is a coherent set. But once this split is 
accepted and agreed upon, what prevents individual developer teams 
from stating that they are unable to meed the general release schedule 
for the KDE SC? Like what happened to KDEPIM (and for good reasons - 
the team rewrote their suite from scratch) and we ended up with a lot 
of questions as to what to ship when, and what dependencies to use 
(or avoid). There is no control mechanism I could find that would 
prevent other teams from taking the same stance. If a split of sources 
into more and smaller tarballs is to become the future release policy, 
then a strict rule about commitment to the overall release schedule 
would be welcome. Else one of the pillars of KDE's strength - 
reliable source releases-  would crumble.

That is why I would vote for keeping the larger monolithic tarballs.

> * Do the split once, try to prevent the git migration mess where we've
>   clearly not thought through the ramifications for release management, which
>   lead to much confusion and frustration among packagers

I absolutely agree that the next step should be more cleanly executed. 
What happened to kdeedu was not pretty, and not discussed thoroughly.

> As we haven't taken any firm decisions, I'd like to invite input from you, to
> see how we can accommodate your workflows and keep the extra work for those
> packaging low. Please do keep in mind that those changes are necessary for KDE
> to move on, since modularizing our platform is an entirely useless effort, if
> those changes aren't reflected in the form they end up on most developers'
> machines.

In the end, for Slackware it will mean more work, but that would be 
largely a one-time effort (like is the case for other teams). We can 
create a modular framework for building KDE. If I don't do it, Pat 
will most certainly do it ;-)
Considering the size of Slackware's "core team" it might delay the 
adoption of KDE 4.7 into the distribution. But that would not be new 
or unusual - while I provide bleeding edge KDE packages in my own 
repository, Slackware is usually a bit behind on KDE releases, and 
with good reasons. Precisely this approach has made the KDE 
experience on Slackware generally a very pleasant one.

> Thanks for your input already. Also please don't wait too long with your
> feedback, since it's essential for ongoing discussions here at Platform11. I
> will be collecting the input and taking it into the discussions going on here.
> (There are some packagers present, but obviously we should give everyone the
> chance to provide input.)
>
> Cheers,

It took a while to read up on mailing list emails, but you caught up 
on me already in other channels, which I do appreciate.

Good luck!

Cheers, Eric

- -- 
Eric Hameleers <alien at slackware.com>
Jabber: alien at jabber.xs4all.nl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/

iEYEARECAAYFAk3tHUAACgkQXlaqr6dcvaCS4ACeP7mqfWJg37qYyzmE0nRP1MwZ
IkgAmwY2Kn3a8t3bfsKhvWQHcSmb7Raf
=of/G
-----END PGP SIGNATURE-----