Your reply is quite confusing, but I'll try to reply to all your points anyway :P<br><br><div class="gmail_quote">On Thu, Mar 22, 2012 at 03:20, Daniele E. Domenichelli <span dir="ltr"><<a href="mailto:daniele.domenichelli@gmail.com">daniele.domenichelli@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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/<u></u>questions in random order.<br>


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

</blockquote><div><br></div><div>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).</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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).<br>


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

</blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2a) Handling small packages is a lot easier.<br>
2b) Building a lot of small packages is complicated, especially if those have different dependencies. But there are scripts for this.<br>
2c) Updating smaller packages is easier, because you can update just some of them.<br>
2d) Updating all the small packages is complicated. But there are scripts for this.<br>
2e) Following the development of a small module is way easier than following the development of a big module (checking the commits, etc)<br></blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>

</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


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


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

</blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
() 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.<br>

</blockquote><div><br></div><div>You can check for example the kde-workspace repo [1]. It has lots of smaller modules, just like we'd have.</div><div><br></div><div>[1] - <a href="http://quickgit.kde.org/index.php?p=kde-workspace.git&a=tree">http://quickgit.kde.org/index.php?p=kde-workspace.git&a=tree</a></div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
æ) Please don't do it, I don't want to change all my scripts again :)<br>
<br>
ð) The unmaintained stuff should just have a section (i.e. Extragear/Review/Playground/<u></u>Unmaintained) but this should be supported by <a href="http://projects.kde.org" target="_blank">projects.kde.org</a>. It's a bad idea to trash it since it contains a lot of valuable code.<br>

</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
:) 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<br></blockquote><div><br>

</div><div>CMakeLists and add_subdirectory, as mentioned above.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
☺) 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.<br></blockquote><div><br></div><div>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 ;)</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
♏) 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.<br></blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
 ) 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".<br></blockquote><div><br></div><div>We are small project, we rarely have problems which would need us bisecting. Especially because the stable and master branches are not /that/ different.</div>

<div> </div><div><div>--</div><div><font color="#666666">Martin Klapetek | KDE Developer</font></div></div></div>