Merge lp://staging/~mterry/gsettings-ubuntu-touch-schemas/volume into lp://staging/gsettings-ubuntu-touch-schemas

PASSED: Continuous integration, rev:30
http://jenkins.qa.ubuntu.com/job/gsettings-ubuntu-touch-schemas-ci/17/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/gsettings-ubuntu-touch-schemas-trusty-amd64-ci/15
    SUCCESS: http://jenkins.qa.ubuntu.com/job/gsettings-ubuntu-touch-schemas-trusty-armhf-ci/15
    SUCCESS: http://jenkins.qa.ubuntu.com/job/gsettings-ubuntu-touch-schemas-trusty-i386-ci/15

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/gsettings-ubuntu-touch-schemas-ci/17/rebuild

Thanks Mike, seems fine to me, can you drop the "touch" namespace?

In retrospect using it was a mistake, we already started moving away from it by renaming the binaries, it would be good to not add new keys to it and just use the ubuntu naming.

Laney, does that make sense to you?

Yes, but we'd have to update the in-progress telephony-service landing and add the schemas to it to rename the keys. I can do that if we decide we want to.

As for this landing, I already expressed my distaste on IRC, but I'll put it here for the record and abstain since I want to defer to others.

I don't like using settings schemas to synchronise state between different parts of the system. In my opinion the session and the greeter ought to be able to communicate things like this between themselves and not go via an intermediary.

And could you please try to keep merge proposals about one change only? The CLEANFILES fix is probably small enough but you also changed SecurityPrivacy here.

Fine, I can take out the CLEANFILES fix and propose a separate branch. I can also take out the SecurityPrivacy change and propose it again after this lands.

I know you don't like this solution. I don't have a strong preference either way, I just want this fixed, and this is the current design spec. We're talking it out in bug 840777 a bit.

It's important to have an intermediary like this. The user session may be open or not. The greeter may be open or not. The backing store must live outside of HOME for permission & encrypted-home reasons. And it needs to be persistent over a reboot. AccountsService seems like the perfect place. And it stores similar related data about users already.

OK, removed touch namespace from my new keys. I didn't change old keys. That can be a separate effort if we want to pursue it.

PASSED: Continuous integration, rev:32
http://jenkins.qa.ubuntu.com/job/gsettings-ubuntu-touch-schemas-ci/19/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/gsettings-ubuntu-touch-schemas-trusty-amd64-ci/17
    SUCCESS: http://jenkins.qa.ubuntu.com/job/gsettings-ubuntu-touch-schemas-trusty-armhf-ci/17
    SUCCESS: http://jenkins.qa.ubuntu.com/job/gsettings-ubuntu-touch-schemas-trusty-i386-ci/17

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/gsettings-ubuntu-touch-schemas-ci/19/rebuild

Just triple-confirmed with John Lea that per-user volume that changes in the greeter is what design wants. Given that design, I think this is the most reasonable way to make that happen.

Seb, can you please re-review?

Thanks Michael. The "use accountsservice to share between session and greeter" is still being discussed/doesn't get consensus, but we agreed in the previous settings meeting to use that meanwhile, so let's not block on it.

I'm comment approving only for now. Laney, if you think that shouldn't go in please comment, otherwise I'm going to approve that a bit later today.

Ok, I'm approving. It might make sense to put that in a silo with the indicator update that's going to use it