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

[Albert Astals Cid]

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?

> 
> The biggest problem I see is that you can't go back in history and
> build stuff anymore.

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.

Albert

> 
> Niko