Merging some repos?

[Martin Klapetek]

Your reply is quite confusing, but I'll try to reply to all your points
anyway :P

On Thu, Mar 22, 2012 at 03:20, Daniele E. Domenichelli <
daniele.domenichelli at gmail.com> wrote:

> I'm a kind of against it, but at the same time I'm a little bit confused
> and tired and perhaps you are right, so here are a few random 3AM
> comments/thoughts/opinions/**questions in random order.
>
> 1) Whatever we choose to do, do not rush. Let's plan this properly. We
> changed everything for 0.3, if we are changing everything again for 0.4 and
> then we realize that something is not good and we change again for 0.5
> packagers, sysadmin and translators will kill us. I suggest to keep this
> structure for 0.4 and eventually start changing right after the release
> (also because the freeze is quite close).
>

The first change would actually be only for the new repos, kipi-plugin and
ssh-contact. If we would create a ktp-utils repo (which makes perfect
sense), then I'd move ktp-send-file there as well as it is just another
utility. I see no point in having a repo for 8 files (send file case).


>
> 8) I don't completely agree with Martin's repository layout, but we can
> discuss this later. Anyway, for ktp-utils in 0.4, ktp-kipi-plugin does not
> belong to any other repository than itself, that repository is an ugly
> temporary hack because libkipiplugin is actually a private library.
> "ktp-kopete-logs-import" should be in a bigger repository
> "ktp-kopete-migrator" and we shouldn't ship it until we can import
> automatically everything we need at first kde login after installation
> (that's how t rush. Let's plan this properly. We changed everything for
> 0.3, if we are changing everything again for 0.4 and then we realize that
> something is not good and we change again for 0.5 packagers, sysadmin and
> translators will kill us. I suggest to keep this structure for 0.4 and
> eventually start changing right after the release (also because the freeze
> is quite close).
>
> 8) I don't completely agree with Martin's repository layout, but we can
> discuss this later. Anyway, for ktp-utils in 0.4, ktp-kipi-plugin does not
> belong to any other repository than itself, that repository is an ugly
> temporary hack because libkipiplugin is actually a private library.
> "ktp-kopete-logs-import" should be in a bigger repository
> "ktp-kopete-migrator" and we shouldn't ship it until we can import
> automatically everything we need at first kde login after installation
> (that's how other migration tools work) so not in 0.4. Thatother migration
> tools work) so not in 0.4. That means in 0.4 a repo for ktp-send-file and
> ktp-ssh-contacts. Perhaps it could make sense if we had at least an app to
> start a call, but again I'd say 0.5.
>

The log thing should be part of the logger itself, which is right now part
of text-ui. So either let's put it there, or let's take the logger out
completely. As for the kipi-plugin - it is an utility, no matter how
hackish, there's no real reason why it couldn't be moved there, especially
if we are going to release it with 0.4. And again - we don't have to go for
the full scheme, it was just an idea, but I'd like to group at least some
of the smaller modules.


>
> 2a) Handling small packages is a lot easier.
> 2b) Building a lot of small packages is complicated, especially if those
> have different dependencies. But there are scripts for this.
> 2c) Updating smaller packages is easier, because you can update just some
> of them.
> 2d) Updating all the small packages is complicated. But there are scripts
> for this.
> 2e) Following the development of a small module is way easier than
> following the development of a big module (checking the commits, etc)
>

Let's not put quantity over quality. We have damn 20 repos. Merging at
least some of them would for example enable easier compile testing, misc
fixes etc. It's just easier to manage less repos than having tonns of them,
pretty much for everyone. I'm not going to start bashing scripts for every
single multi-repo operation I would like to do.


>
> w) Dependencies on KDE is a very big problem for me. I'm running Debian
> testing, so I don't have KDE 4.8 yet, therefore if you have small
> components and one of them depends on 4.8 I can have almost all of them, if
> you have bigger you need to write complicated cmake scripts. Also this will
> be a problem if someone wants to bump the version because he needs
> something, but someone else don't want it because his distribution don't
> package that version yet.
>

You don't need complicated scripts, it could be a simple CMakeLists.txt
with add_subdirectory(..). You can simply comment what you don't want to
install.


>
> %) Git allows submodules. You can make a ktp package without merging the
> repositories. Handling submodules is not really easy, but you can write
> some scripts and cmake custom targets for that. Using submodules you could
> update just one component. If you just want to do a "super-repo", imho
> that's the way to go... A super-repo that can build everything, but you can
> still build just one module.
>
> £) Submodules have also advantages. For example if you push something in
> ktp-common-internals and you need to update some other repositories, people
> will start complaining on irc that stuff is not building or doesn't work
> any more (trust me, 15 seconds are enough). If you have a repo with
> submodule you can push your changes to the submodules and then update the
> "meta" repository in just one commit without breaking anything.
>

Given the experience we had with our last submodule, which drove everyone
crazy (and I imagine it drove Dario to tears :D ), I would be careful
around this as we need to do it properly.


>
> () This is not a problem that only ktp has, this is a problem also for KDE
> modules, perhaps they have already thought how to handle this. I think that
> in Qt5 they are already doing something similar. Before doing anything we
> should check how they have planned this.
>

You can check for example the kde-workspace repo [1]. It has lots of
smaller modules, just like we'd have.

[1] - http://quickgit.kde.org/index.php?p=kde-workspace.git&a=tree


>
> æ) Please don't do it, I don't want to change all my scripts again :)
>
> ð) The unmaintained stuff should just have a section (i.e.
> Extragear/Review/Playground/**Unmaintained) but this should be supported
> by projects.kde.org. It's a bad idea to trash it since it contains a lot
> of valuable code.
>

No it doesn't. The only valuable code is the testlib (which is actually
being used, though unmaintained) and perhaps the ktp-kde, but that's about
it.


>
> :) SVN was basically a huge repository, but you were able to get just one
> component and build just that, with git you can do the same, but if you
> merge repositories into one you lose this ability
>

CMakeLists and add_subdirectory, as mentioned above.


>
> ☺) For a packager it might be boring to do a lot of packages, but that
> also make their life easier, because they don't have to split stuff, we
> already do it for them.
>

I'm not sure they want to split stuff. Distros do metapackages, which does
the exact opposite - install everything in one go. That's somehow my idea,
people install just everything. And it's better to have and not need than
need and not have ;)


>
> ♏) I'm not expecting any of our component to be replaced by someone with
> another component, I'm expecting exactly the opposite: empathy users using
> some of our components.
>

Tbh, I don't. Let's be realistic. It's a nice theory and stuff, but in
practice doesn't really work with cross-desktop stuff. We're using KClasses
in our components, that means that gnome desktop would have to load kdelibs
and stuff around that if anyone would want to use Empathy with KTp. And
again - during the whole time I haven't seen a single comment about Empathy
and KTp cooperation. People just don't do that and I'm not expecting them
to. Different thing would be if there were two KDE Telepathy
implementations. However there are not.


>
>  ) Bisecting is a lot faster with small repositories, and this alone is in
> my opinion a very good reason not to switch to "super-repositories".
>

We are small project, we rarely have problems which would need us
bisecting. Especially because the stable and master branches are not /that/
different.

--
Martin Klapetek | KDE Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20120322/e6de47a9/attachment.html>