KWallet/KSecretsService & GIT workflow

[Valentin Rusu]

Hello,

KSecretsService API is now nearing the finished state. But this would be
confirmed by starting using it as a KWallet API backend. Naturally, I'll
do this on my system but I'd like to do it such that:
- allow for current kdelibs modularization efforts,
- allow volunteers to test this new feature,
- ease the "playground to kdereview to kde-???" process,
- easy merging to master when code become stable enough.

KSecretsService is intended to supersede the KWallet infrastructure.
It's structured in several modules:
- Client API -- intended for KDE applications as a KWallet API
replacement; behind the scenes it's using DBus to call the deamon, but
that's an implementation detail,
- Daemon -- implementing a DBus freedesktop.org specification (see [1])
and doing the actual secret management on disk (and hopefully on
smartcards),
- SecretSync tool -- intended to allow secrets synchronization among
several devices.
All these modules now live together inside one playground GIT repository
[2].

One more component should be the KWallet backend, an implementation of
the current KWallet class based on the new "Client API". KWallet code is
actually spread inside several GIT repositories: kdelibs, kdeutils and
kde-runtime. I think that I should do a branch named "ksecretsservice"
inside each of these repositories, then start using the new "Client API"
and do the switch to the new infrastructure. When this might become
"showable", I might push these branches to each of thses repositories,
along with an appropriate announcement to this list.

Any thoughts about this process? How does it fit with current kdelibs
modularization process?

[1] http://specs.freedesktop.org/secret-service/
[2] https://projects.kde.org/projects/playground/base/ksecretservice