Merging some repos?

[Rohan Garg]

Hi Martin
As a packager down stream .. please make up your mind! It gets
difficult downstream to track what packages should be removed from a
user's system when installing the new version and what new stuff
should be pulled in when installing this new release. Note that I'm
not against this, just making a decision and sticking to it would
suffice so that downstream doesn't have to redo a major chunk of the
packaging again.

Best
Rohan Garg

On Thu, Mar 22, 2012 at 4:51 PM, Martin Klapetek
<martin.klapetek at gmail.com> wrote:
> 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
>
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy
>