[Kde-scm-interest] Re: [Kde-pim] Re: Re: Fwd: KDEPIM Git Move

[Volker Krause]

On Saturday 06 November 2010 18:34:19 Tom Albers wrote:
> ----- Original Message -----
>
> > On Saturday 06 November 2010 12.50.34 you wrote:
> > > ----- Oorspronkelijk bericht -----
> > >
> > > > On Saturday 06 November 2010 09.58.22 Niko Sams wrote:
> > > > > On Fri, Nov 5, 2010 at 12:49, Torgny Nyblom <kde at nyblom.org>
> > > > >
> > > > > wrote:
> > > > > > On Friday 05 November 2010 09.00.48 you wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Could you please shortly explain the used repository layout.
> > > > > >
> > > > > > I'm not really sure what you mean?
> > > > > >
> > > > > > kdepim will be split into kdepim and kdepim-runtime modules in
> > > > > > git.
> > > >
> > > > This
> > > >
> > > > > > is a split that relects reality as those are two modules
> > > > > > living
> > > >
> > > > under
> > > >
> > > > > > one directory in SVN.
> > > > > >
> > > > > > kdepimlibs will be kdepimlibs in git as well.
> > > > >
> > > > > Ok, that's whant I wanted to know....
> > > > >
> > > > > Why don't you split kdepim into individual applications?
> > > > > (as you have already libs and runtime split)
> > > >
> > > > Since there are way to many interdependencies between the
> > > > different
> > > > applications/libraries. The only way that the PIM code makes any
> > > > sence
> > > > is as a
> > > > whole.
> > >
> > > It would make sense to split kdepimlibs though.
> > >
> > > They are already fully independent and it would make it more
> > > attractive to
> > > be used by others.
> > >
> > > Pimlibs is considered as a big monolitic library blob, while that is
> > > not
> > > true. Especially in the mobile world it would be good to have a set
> > > of
> > > small separate libraries, and in fact that is what pimlibs is.. It
> > > would
> > > make the individual bits of pimlibs more attractive to use by apps.
> > >
> > > I'ld advise to split pimlibs.
> >
> > Would that mean each lib on it's own or?
>
> Yes, I would make a git repository per library. For example kimap can then
> be build straight forward and on its own, without pulling in the sources of
> ktnef or microblog.
>
> On projects.kde.org we can group all these into kdepimlibs, for example see
> how that is done for telepathy on https://projects.kde.org/projects We are
> also working on an xml file, which makes it possible to say to kdesvn-build
> that you want kdepimlibs and it will pull in all the libs.
>
> This way you have the advantages of splitting and the disadvantage of the
> fragmentation minimized.
>
> But then, I'm in no position to decide, that's up to you and the pim
> people. I just wanted to have it said so you all can give it some thought
> and consider it.

kdepimlibs has currently about 20+ libs in it, not all of them are 
independent, probably about half of them depend on each other in obvious and 
not so obvious ways. IIUC you would need to check out all of them 
individually and then figure out the dependencies manually (something that 
cmake currently does for us)? Sounds very inconvinient and would basically 
force the use of a tool such as kdesrc-build to do the job for you.

While making things more modular is of course a very desireable goal, I'm 
wondering if we really need one repo per lib for that? It wont magically 
reduce dependencies, and it's not exactly making it easier to use single 
libs. To stay with the KIMAP example, you'd need KMime for that, as well as 
kpimutils (build time only), three repos instead of one.

IMHO reducing/clarifiying dependencies, allowing to compile only the desired 
sub-sets and advocating split-up packaging could help more than individual 
repos. While they make the dependencies more obvious (and thus hopefully make 
you think twice before adding a new one), they come with a considerable price 
it seems.

How is this handled in kdelibs btw? I guess following whatever is done there 
makes most sense, so things are consistent in the main KDE repos.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20101108/0d3f30c9/attachment.sig