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

[Niko Sams]

On Tue, Dec 28, 2010 at 00: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
yeah, but that doesn't work that easy in graphical tools like qgit.

>
>> 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
True. But in svn there was just the stable branch for most applications. Once we
use git, lots of branches will be created (mainly local ones and in
cloned repositories)

>
>> 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?
I said "to solve this with split repos", not split is the proper way.
I'm not in the position
of saying wether kdegraphics should split. The developers of that
module have to decide that,
they know how development happens.

> Complainig aside and knowing i won't win this discssion, the biggest problem
> is finding someone to do the needed code to make those changes happen and
> maintain the library.
+1


Niko