[proposal] KSecretsService components moving from playground

[Steven Sroka]

>On 11 October 2011 18:24, Valentin Rusu <kde at rusu.info> wrote:
> Hello,
>
> As KSecretsService becomes quite usable, I think it's time to prepare to get
> it integrated into the next release.
> http://techbase.kde.org/Schedules/KDE4/4.8_Release_Schedule
>
> The code is not yet fully mature, all the components are not yet finished,
> but the main parts are there and it is now possible to have secrets stored
> in KSecretsService and konqi or microblog successfully getting them upon
> session start. There is a checkbox in the KDE Wallet configuration tool that
> switch KWAllet API to KSecretsService when checked. It will be left
> unchecked for the next release.
>
> Components are:
> 1. KWallet API - already in kdelibs branch ksecretsservice,
> 2. ksecretsserviced - still in playground,
> 3. kwl2kss -  still in playground,
> 4. ksecrets - still in playground
> 5. secretsync - still in playground.
> 6. kio - still in playground
>
> Components needed for 4.8 are 1., 2., 3. and 4. Therefore I propose to move
> them out of the playground as following:
> 1. get merged into 4.7 branch before 4.8 branch is created
> 2. goes to kde-runtime,
> 3. make it part of kdeutils/kwallet [see complement below]
> 4. create a kdeutils/ksecrets repo for it and for 5. and 6.
>
> Complement:
> kdeutils/kwallet has a branch containing code specific to ksecretsservice
> (e.g. the checkbox to activate ksecretsservice infrastructure). This branch
> should also be merged when releasing 4.8.
>
> Any thoughts?

I sincerely don't mean to be an *ss and I do say this in good faith,
but you say "The code is not yet fully mature, all the components are
not yet finished". Given that downstream distros and users are still
struggling with some rather bad bugs from previous versions of KDE,
would it not be prudent to push the first release of KSecretsService
until it is completed and all the components are finished?

I personally have been looking forward to KSecretsService and I like
the idea of leaving KSecretsService unused by default for now, but it
should at least be stressed to downstream to leave it off by default
and why you chose it to be off for this release, if you do decide to
implement it for 4.8. I assume there is a reason you decided to leave
it off by default?

Anyway that is just my 2cents, and I will follow whatever decision you
make. You are a better judge of the quality of KSecretsService than me
:)

>
>
> --
> Valentin Rusu (IRC valir, KDE vrusu)
> KSecretsService (former KSecretService, KWallet replacement)
>
>