kdelibs (tier1) splitting package/repository granularity

[Alexander Neundorf]

On Friday 11 May 2012, Kevin Ottens wrote:
> On Thursday 10 May 2012 23:00:16 Alexander Neundorf wrote:
> > On Thursday 10 May 2012, Kevin Ottens wrote:
> > > On Wednesday 9 May 2012 21:38:55 Alexander Neundorf wrote:
> > > > I understand correctly that tier1 libs do not have any dependencies
> > > > between each other, right ?
> > > 
> > > Correct.
> > > 
> > > > Do we plan to put each of those into a separate repository and
> > > > release as
> > > > a separate package ?
> > > 
> > > Correct. Still some work needed before we get there though, we're
> > > waiting for the last possible moment to do the splitting.
> > 
> > Hmm, not sure I really want to say this, but...
> 
> Then don't? (always find this kind of sentence weird, sorry, couldn't
> resist)

s/want/dare/

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 ?

> > no runtime dependencies.
> 
> Not correct. We'll have tier1 with runtime dependencies at some point. We
> sort out runtime and link time dependencies on two different axis. The
> "tiers" form the link time dependencies axis.
> 
> > Why not put all tier1 libraries into one repository and release them as
> > one package ?
> 
> 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.

> > Keep tier2 and tier3 libraries, or those which introduce different
> > runtime dependencies, or those which are "big", separate.
> 
> Define big? :-)
> Predict what will become big tomorrow?

That's why I put it in quotes.

> > qxt does this too, and it's no problem for 3rd party users.
> 
> Well, the whole of libqxt is under 120 classes, so clearly a different
> scale than kdelibs, and already smaller than our likely incomplete current
> tier1. Also I'd be curious to know where the "no problem for 3rd party
> users" claim comes from. AFAIK it's about as successful as kdelibs for 3rd
> parties... that is: not used much.

Own experience.
No problems at all with it.
The license is ok, no dependencies except Qt, building static works.
That it contains 5 libs or so is absolutely no problem in my case.

...
> > Having the tier1 libs in one repository would at least make maintaining
> > the buildsystem easier (simply less work),
> 
> Yes, I see the incentive there.


I counted yesterday on the splitting epics page. According to it, kdelibs will 
turn into around 30 separate repositories.
Each of those should have a maintainer.
But I think we don't assume that the maintainers also maintain their 
buildsystem, or do we ?
Currently it's mostly Stephen (and me).
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.
 
> > and it may make building the whole
> > thing a bit more convenient, since you have less packages to build.
> > For kdelibs developers it would be probably also a bit more convenient.
> 
> Well, they'd have to handle the tier2 and tier3 repos anyway... so back to
> square one.

Somewhat.
It would be maybe 10 or so repositories less.

> > Of course each of the libs can be switched on and off separately...
> > 
> > So, what are the real benefits of e.g. releasing the 6-file library
> > kdbusaddons as a separate package ?
> 
> Well, the points I mentionned above, and on top of that:
>  * Tier positioning of a repo becomes "just" a label, so no weird
> merging/splitting repo operations if the situation of a lib has to change;

Ok, with git this is an issue.

>  * Consistency in the way we deal with the frameworks accross the whole
> offering ("aaah you wanted kdbusaddons this time? well contrary to the
> other ones you worked on, it is in a special repo with other tier1").

Hmm, well.
This would be the "plain simple libs feel-good" repository.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120511/da15705d/attachment.html>