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