[Kde-scm-interest] Package splitting

[Mark Kretschmann]

On Tue, Jan 26, 2010 at 1:39 AM, Troy Unrau <troy.unrau at gmail.com> wrote:
> I'm not really involved, nor do I particularly care what SCM KDE is
> using - that's not the reason I'm here. I do however hope that we can
> kill two birds with one stone, and that's the package splitting
> monster. If it's reasonable to accomplish at the same time as the git
> transition, it'd be nice to be able to split out the kde applications
> into separate packages. My motivation for such is two-fold:
>
> 1) We have a mess right now with each distro splitting KDE in a
> more-or-less unique way, except slackware. This makes it hard to
> recommend packages to users when doing tech support.
> 2) From a marketing perspective, we'd like to start marketing the
> various KDE applications independently, which requires that they are
> easier to obtain as stand-alone apps. In other words, we'd like to be
> able to offer a download of Okular by itself, for instance, since
> Okular is good enough to sell itself.
>
> I realize that this tips into the release management stuff somewhat as
> well, but hopefully most of them are on this list. Secondly, I know
> that it would create a lot of additional work during the transition,
> but I'd make an argument that it's better to have a major break to
> workflow once (git+splitting) versus twice (once for git, once later
> for splitting).
>
> Feedback requested. Thiago told me that ossi has already brought this
> up somewhere, but I haven't grepped through the archives yet.

Here's what I would recommend (I had talked this over with Aaron on
IRC once already). It's just my personal view, but after all, we
(Amarok folks) have some experience with Git workflows now:

1)
Put each application in separate repositories.

Don't put it all in one repo, like ExtraGear tried it in SVN. Some
believe that this makes it easier to build and maintain all this, but
in reality it's exactly the opposite. If you want to build, say,
"digiKam", you may not be interested in building "KPovModeler" as
well. And even if you wanted to do that, it could be scripted easily,
with something like KDESVN-Build (Michael Pyne is working on a version
for Git, I heard).

2)
As a next step (this might sound a bit radical): Decouple most
applications from KDE's release cycle.

Let's for example take Dolphin. Not very long ago, I read something
from Peter Penz along these lines: "Damn, I missed the feature freeze
again. Sorry, but this one will have to wait for the next KDE
release!". But why is that necessary? Penz could create his own
release cycle that fits his development style best, and when he
releases, then the distros and users can decide if they want to use
this new version. It's all up to the distro packagers anyway, they are
slicing-and-dicing already now (Gentoo does this a lot).

-- 
Mark Kretschmann
Amarok Developer
Fellow of the Free Software Foundation Europe
www.kde.org - amarok.kde.org - www.fsfe.org