kdelibs (tier1) splitting package/repository granularity

[Kevin Ottens]

On Monday 14 May 2012 21:43:06 Alexander Neundorf wrote:
> On Monday 14 May 2012, Kevin Ottens wrote:
> > 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.
> 
> I really tried since early 2006 to keep the kdelibs buildsystem pretty, a
> bit less kdebase and kdepim(libs), so those could serve as samples. From
> time to time I looked at the other modules of KDE SC, but much less often.
> 
> I tried to educate everybody who had a question how to do it properly, even
> if it took me two weeks, while I could have simply fixed it in one or two
> evenings.
> 
> I tried to document it properly on techbase, I documented all changes (until
> 4.6 or so) between each major releases, I wrote coding style howto, a
> compatibility policy.
> 
> I wrote documentation in the cmake wiki.
> 
> I blogged about it from time to time.
> 
> I'd consider this good enough documentation.
> 
> So I actually think I did a quite good job with that...

Sorry, I didn't mean you did a bad job in the past. Just pointing out that the 
thing already looks very different from what we had in the past, and so... the 
documenting effort will have to be pretty much redone. That's necessary (but 
obviously not sufficient...) step if we want to get a chance to have 
maintainers maintaining the buildsystem of their framework.

> [...]
> My impression from many autotools-based projects is that their buildsystems
> are a lot of copying around from other existing projects, because they
> contain stuff the developers don't understand and so don't want to touch
> it.
> 
> I want to avoid this, and instead of having a convenient function or file
> which does everything, have a sequence of simple and understandable steps.

I hope you succeed. The challenge though is that there's nothing like an 
"apidox for build". It's not easy for people to write from scratch so they end 
up copy/pasting.

> > > 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).
> 
> That's all I wanted to get, some thinking about whether some sensible
> grouping is possible, instead of simply splitting everything :-)

*sigh* Of course we never put any thinking before right?

"splitting everything" can't be further from the work which has been going on 
so far (nor the ideas jotted at Platform11). When it makes sense we group (see 
kconfig for instance as latest incarnation of that...). We're not aiming at 
one lib per repo, we're aiming at one framework per repo... and yes sometimes 
it'll be a single tiny lib if it can't be grouped with something else. For 
some cases it's easier to find the right groups than others, the k*addons 
(potential) group I gave earlier is stretching a bit IMO, but that's an 
option.

Anyway that's why I keep thinking it's too early to split the repositories. We 
keep moving the lines in the libraries, and also in how we group the 
libraries.

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/4eb02a9d/attachment.sig>