Merging some repos?

[Daniele E. Domenichelli]

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).

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.

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)

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.

%) 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.

() 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.

æ) 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.

:) 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

☺) 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 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.

  ) 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".


Now I'm tired, but if you read the whole mail you are probably tired 
too, so goodnight.

Daniele