kdelibs (tier1) splitting package/repository granularity

[Kevin Ottens]

On Friday 11 May 2012 22:55:37 Alexander Neundorf wrote:
> I mean, I'm all for modularisation, making it easier to use parts of kdelibs
> instead of the whole thing.
> But is it really necessary to split each tiny lib into their own repository
> ?

Well, obviously I think it is for consistency and future proofing.

> > Well, that's *today* situation. We know how it works really, introduce a
> > lib and it'll likely grow overtime. Put a set of libs in a common repo,
> > and it'll be veeery tempting to sneak a dep here or there. Can't harm
> > right? :-)
> 
> I'd go so far that maintaining the buildsystem of a repository containing 10
> libraries (and watching out they don't introduce dependencies) may be
> easier than maintaining 10 separete buildsystems.
> At least it's not a clear cut.

Sure it's not a clear cut like any trade-off. Depends what you value most 
really.
 
> I counted yesterday on the splitting epics page. According to it, kdelibs
> will turn into around 30 separate repositories.

And it'll probably be even more once kdepimlibs and others join the party as I 
expect it to happen.

> Each of those should have a maintainer.

We have troubles with that, but that's the intent.

> But I think we don't assume that the maintainers also maintain their
> buildsystem, or do we ?

Just to make sure I'm not making wrong assumptions here, could you briefly 
list me what tasks you have in mind under "maintain their buildsystem"?

Right now, by default I'd expect maintainers to also maintain their 
buildsystem. *But*, it'll have to be documented what should be in the 
buildsystem and how. We need a clear reference point for framework 
maintainers, otherwise they'll just let it rot in a corner as they did in the 
past.

Also, it has to be made as simple as possible for the default cases I think. I 
don't think we succeeded at that in the past, but what I've been seeing so far 
in the splitted frameworks is a very good improvement already.

> Currently it's mostly Stephen (and me).

Yes, and I'd expect that to be the case for some time to come. It's changing 
so fast at the moment than it's hard to keep up. :-)

> While the size of the source code does not increase with the splitting, the
> size of the buildsystem grows linear with the number of the repositories.
> 
> Maintaining 30 buildsystems is a lot more work than maintaining 1 as it was
> in kdelibs.
> 
> For me, that's a valid argument for putting tier1 or tier1-no-runtime-deps
> libs into one repository, and by this decrease the number somewhat.

Sure, as I said previously I see the incentive. As you can see, I'm not 
convinced that this reduction is worth it compared to the value of having 
something consistent accross all modules.
Not that I wouldn't welcome such work reduction, it's just that the percentage 
will be around 15% roughly.

Now, trying to think a bit outside of my own mind box, there might be still 
some groupings which could be done while not confusing people over where is 
what:
 * The tier4 frameworks could all go together, since they share a same topic 
by nature (it's the consistency frameworks), exception there is probably the 
kde*support ones which are better separated;
 * The k*addons ones could be grouped in a single framework... In fact that 
would make sense somehow, since each of those will contain a small set of 
classes which "augment" Qt with a thin layer of utility classes (they're 
clearly our weak spot here, they could derail in dumping grounds).

But anything else which has a much more narrow feature scope (which ought to 
be the majority of the frameworks) must not be grouped in my opinion.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120514/92e495f4/attachment.sig>