-----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 <[email protected]>
Jabber: [email protected] -----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-----
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
