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
_______________________________________________
KDE-Telepathy mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-telepathy
