[Kde-scm-interest] Re: kdegraphics libs migration

[Ian Monroe]

On Mon, Dec 27, 2010 at 17:45, Albert Astals Cid <aacid at kde.org> wrote:
> A Dilluns, 27 de desembre de 2010, vàreu escriure:
>> On Tue, Dec 28, 2010 at 00:11, Albert Astals Cid <aacid at kde.org> wrote:
>> > A Dilluns, 27 de desembre de 2010, Marcel Wiesweg va escriure:
>> >> > I read your mail and sincerely it seemed like "we screwed up with
>> >> > those libs and don't know what yo do, help!". Since i know nothing
>> >> > about git I can't help.
>> >>
>> >> I dont think we screwed up. Rules are written and repos look quite good.
>> >> We dont need help, I just want to talk about those libraries which we
>> >> write, need, maintain, and share.
>> >
>> > Good then sorry for misreading :-) Unfortunately i don't use any of those
>> > libs so don't have much input there.
>> >
>> >> > If you ask what is my personal opinion as Okular maintainer
>> >> > i'd prefer a non split repo.
>> >>
>> >> Well, we went for a non-split repo with digikam et al and the answer
>> >> from sysadmins was pretty clear (monolithic a no-go). I've seen
>> >> different opinions on this list, but I can now, technically, only agree
>> >> with the split-repo approach: Why should one who wants to code a patch
>> >> for gwenview or libksane have to download okular's full history?
>> >> Remember that git is a bit different to SVN in that respect.
>> >
>> > The same question applies to SVN, why should one want to download
>> > gwenview code to code in libksane? The answer was because we were
>> > supposed to help eachother and more people downloading and compiling
>> > your code meant more people possibly being ready to help. But people
>> > helping eachother is an old fashioned way of thinking amonsgt KDE
>> > younglings it seems.
>>
>> Downloading is not much an issue - you do it only once.
>> What more is an issue is that git looks for most operations at the
>> whole repository.
>> For example pulling with local (commited) changes: if you dont --rebase you
>> get a (useless) merge commit.
>> Or git log always shows the whole module history, tough you are only
>> interested into onto application.
>
> You can do "git log okular" if you are interested in the okular log only
>
>> Or branches always branch the whole module, tough the branch is only ment
>> for one application.
>
> Reallly? http://websvn.kde.org/branches/KDE/4.6/kdegraphics/ seems like a
> branch to me
>
>> Yes, this is a disadvantage of git, but we have to cope with that.
>
> Yes, we have to cope with git disadvantages because it was forced on us that
> don't like it by the yous that like it, but i will still complain when I can
> since i think that destroying the development model we've used for ages
> because the SCM is not up to par with our requirements is something that seems
> like a bad idea.
>
>>
>> > Besides that philosophical rant there's a problem with okular,
>> > thumbnailers and strigi-anaylxer code that does
>> > ../../libs/mobipocket/mobipocket.cpp (yeah going back in your path
>> > outside "the project") and will obviously break if you do a split repo.
>>
>> kdeedu has the exact same problem with libkdeedu.
>
> No, libkdeedu is a library already, libs/mobipocket/ is not.
>
>> The proper way to solve this with split repos is to install mobipocket and
>> find it using cmake. The lib must install headers and everything then.
>
> So kdepim and calligra developers are dumb or something since they went the
> non proper way?

No of course not. The decision on whether to split or not hinges on
how cohesive a module is. How often do people make cross-submodule
commits? If the devs do so often, splitting is a bad idea. But if they
don't, then its really just easier to split. Smaller modules make it
easier to build and develop one thing and easier to move around to
different locations in KDE.

And the only people who know how coupled & cohesive kdegraphics is are
the kdegraphics developers. kde-scm-interest is not the correct forum
to decide that (or at least, it shouldn't be the primary place to
discuss it).

Ian