kdelibs (tier1) splitting package/repository granularity

[Kevin Ottens]

On Monday 14 May 2012 22:25:30 Alexander Neundorf wrote:
> On Monday 14 May 2012, Kevin Ottens wrote:
> > 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.
> 
> Yes.
> One of the things I'd like to do quite soon is put an example into the
> kdeexample/buildsystem/ directory for how to install a library using cmake
> 2.8.8 (the example which is already there uses cmake 2.6 features).

That'd be a nice start indeed.

> > [...]
> > I hope you succeed. The challenge though is that there's nothing like an
> > "apidox for build".
> 
> http://api.kde.org/cmake/modules.html :-)
> 
> ...

Meh... how come I didn't know this?
Looking at it I'm overwhelmed though, from the list of modules I wouldn't know 
where to look for a task apart from the Find* ones... OTOH it's probably the 
most common case.

> > > 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.
> 
> That's good :-)
> You know, when I got the answer that every library in tier1/ and tier2/ is
> supposed to be moved into a separate repository this did not sound as what
> you describe.

Well, I guess it comes from a common misunderstanding. I'll put the answer 
here: framework != library.

So at end game every subdirectory in tier* directories will be splitted in a 
separate repository yes. But, each subdirectory is supposed to be a complete 
framework, which might contain a single library, or several libraries, or even 
runtime tools. The main criterion for groups is if it's focused feature wise, 
which is both a slightly fuzzy concept and hard to reach in some cases.

It's one of those things I want to document on the wiki but when I'm done with 
all the emails I get... I just crash on my bed. :-)

Now currently we indeed prepare quite a few "single library" frameworks. That 
comes in part from the way we listed things during Platform11, and also the 
way we do the work in git right now. Doesn't necessarily mean it'll stay that 
way up until we split. I don't think I'm known for making big upfront plans 
set in stone and I didn't believe we could get a perfect picture at Platform11 
of the whole of kdelibs (clearly we didn't). I prefer to put some corner 
stone, let go with the flow, and adjust the course when something arise. In 
other word, take decision at the last possible moment.

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/282a9ad4/attachment-0001.sig>