[pulseaudio-discuss] [PATCH] module-gsettings: new module to store configuration using gsettings

[Tanu Kaskinen]

On Sun, 2016-09-11 at 10:24 +0530, Arun Raghavan wrote:
> 
> On Sat, 10 Sep 2016, at 10:26 PM, Tanu Kaskinen wrote:
> > 
> > On Sat, 2016-09-10 at 21:58 +0530, Arun Raghavan wrote:
> > > 
> > > 
> > > On Sat, 10 Sep 2016, at 02:06 PM, Tanu Kaskinen wrote:
> > > > 
> > > > 
> > > > On Sat, 2016-09-10 at 09:06 +0530, Arun Raghavan wrote:
> > > > > 
> > > > > So unless MATE and co. are actually using it, I don't think it's a bad
> > > > > idea to drop it (the paprefs dep can be upgraded to latest PA with
> > > > > gsettings-only support).
> > > > 
> > > > If the data migration is not entirely smooth for users, I want to let
> > > > distributions choose when to drop gconf support.
> > > 
> > > Sure, making sure there's a smooth transition is important, but IMO it's
> > > orthogonal to supporting GConf. It's not great to have GSettings as an
> > > option and then push the decision of whether config should break or not
> > > out to distribution.
> > 
> > Do you mean that it's worse to provide a gsettings option that has
> > glitchy data migration than to provide no gsettings option at all? I
> > think that depends on how high distributions set their bar. If I was a
> > distribution maintainer, I would stay with gconf until a smooth
> > migration is available. If all distribution maintainers are like me,
> > then I agree, we should block gsettings support until this is fully
> > sorted out, but if I've understood correctly, Sylvain is working on
> > Fedora, and his patches are less-than-perfect in this regard, which
> > suggests to me that Fedora perhaps doesn't care that much about the
> > migration problems.
> 
> We shouldn't block it, but I do think we should recommend that people
> hold off switching until we have a clean migration path.

Certainly. This needs to be explained in the release notes, and
gsettings should be disabled by default (like it is in this patch).

-- 
Tanu