Merging some repos?

[David Edmundson]

2012/3/21 Martin Klapetek <martin.klapetek at gmail.com>:
> On Thu, Mar 22, 2012 at 00:04, David Edmundson <david at davidedmundson.co.uk>
> wrote:
>>
>> 2012/3/21 Martin Klapetek <martin.klapetek at gmail.com>:
>> > 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
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy
>