2012/3/21 Martin Klapetek <[email protected]>: > On Thu, Mar 22, 2012 at 00:04, David Edmundson <[email protected]> > wrote: >> >> 2012/3/21 Martin Klapetek <[email protected]>: >> > Hi all, >> > >> > I'd like to bring up our current repos status. Right now we have 19 ktp >> > repos and telepathy-logger-qt repo, totaling it to 20 repos for ktp. >> > From >> > these are 5 repos unmaintained/not developed (the old nepomuk stuff, >> > kded >> > launcher and testlib/tool). While I do understand why we have so many >> > repos, >> > I think it's good time to step back and look at it. >> > >> > I know our philosophy is to have small, separate components, which can >> > be >> > easily exchanged for others. But let's face it - there are no others and >> > probably won't be anytime soon. Of course you can use Empathy in >> > combination >> > with ktp, but I've tried it few times and it does not work that well and >> > I >> > don't know anyone using it like that (also there wasn't a single bug >> > report/wish/mail mentioning cooperation with Empathy). I don't want to >> > create one single app, but just group few repos together, the components >> > are >> > still going to be separated and fully exchangeable. We'll just provide >> > smaller amount of packages with easier way to install (and everybody >> > installs all our stuff anyway). >> > >> > Do we really need a separate repo for every single tool/utility we add >> > to >> > our suite? These could be easily grouped under one single repo, say >> > ktp-utils. For all our plasma-stuff, David is going to create one single >> > repo. I think it would be good to extend it to others as well. >> > >> > I propose to merge some repos into one and create several "super repos", >> > basically just a repo with simple subfolders, compilable all at once >> > (super >> > CMakeLists.txt), here's the scheme: >> >> When? 0.4 or just long term thinking? We've already done a massive >> shift around which was a massive pain in the ass so that we (quote) >> "on't have to change them again". > > > I'd go ktp-utils for 0.4, the rest is long-term (if at all). However this is > not as massive change as renaming, it's just moving stuff around. > Ok, I'm fine with that (for the first 3 anyway). Send-file is the only one with a repo currently anyway. So it's more just moving new stuff into the same repo, rather than actual merging.
DrDanz gets the most important say on this, as kipi-plugins and ktp-ssh-contact are his projects. Btw (offtopic), I'm a bit scared of ktp-ssh-contact, not because it's actually dangerous (especially our part which is just a tiny gui wrapper anyway), but because of the paranoid people kicking up a massive stress for no reason without actually understanding it. Anyway, I don't want people blogging about it before I've added support in the approver, and I might talk to upstream (Tp) about how they handle marketing it. >> >> >> > ktp-utils >> > - ktp-kipi-plugin >> > - ktp-send-file >> > - ktp-ssh-contact >> > . ktp-kopete-logs-import(?) >> >> We need to be a bit careful about making an app for every single stream >> tube. >> >> > >> > ktp-workspace-integration >> > - ktp-contact-runner >> > - ktp-kded-module >> > >> > ktp-plasma >> > - ktp-contact-applet >> > - ktp-presence-applet >> > - ktp-contact-list-applet(?) - this is already being merged into >> > ktp-contact-applet. I am also intending on merging the chat plasmoid in >> > here >> > too. I think this is already underway. >> >> >> > >> > ktp-base >> > - ktp-accounts-kcm >> > - ktp-approver >> > - ktp-auth-handler >> > - ktp-call-ui >> > - ktp-common-internals >> > - ktp-contact-list >> > - ktp-filetransfer-handler >> > - ktp-nepomuk-service >> > - ktp-text-ui >> >> I'm not so sure about this. > > > This set could actually stay the way it is now (ie. no super-repo). > >> >> >> >> > ktp-unmaintained >> > - ktp-kde >> Controversial! Aren't you the one maintaining it? > > > No, we're working on kpeople, which is a different library. > >> >> > - ktp-launcher-kded >> > - ktp-presence-dataengine >> > - ktp-test-tool >> > - ktp-testlib >> > >> This is pointless, they should just die. No point merging them to kill >> them. > > > Last time we spoke about this George said it's bad to "just kill them" as > they still contain valuable code. This is not exactly true for the > test-tool, which was extended into full contact list. The testlib is > currently being used by Vishesh to test the Nepomuk stuff. The dataengine is > afair broken and crappy. The launcher is not being shipped nor used. > Yeah, test-tool was a stupid idea. (well, it wasn't a stupid idea at the time. you just finished the contact list far quicker than I expected!) I'm the "maintainer" on that, and I say should just die and that it contains nothing of value. >> >> > >> > It's just an idea and I'd like to hear your opinions, especially from >> > packagers, so please speak up :) >> > >> >> I agree our situation is a bit annoying, but it's not /that/ broken >> either. >> >> In theory we make: >> Packagers lives easier (not splitting up binaries from a repo into >> packages (not sure if true)) >> Our lives easier (merging is hardly ever a problem due to this, and >> each module has it's own maintainers) >> >> So who does that leave? >> people who want to compile our code from git themselves for some >> reason. They should just use kdesrc-build and I don't care about these >> people anyway they're often annoying anyway (except alin and einar >> obviously) >> >> I agree we should "cut down slightly", that's why I'm merging my >> plasmoids into one place - but I don't see the need to go overkill the >> other direction either, especially as changing massively again is >> going to piss people off as much as help them. > > > Of course we don't have to go the overkill way and merge just the plasma and > utils stuff for example. It's not a finished plan in any way, just a > brainstorming that I put up for discussion. +1 for brainstorming :) > -- > 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
