Re: Requiring systemd for the gnome-settings-daemon power plugin

[Bastien Nocera <hadess hadess net>]

On Tue, 2012-10-23 at 08:53 -0400, Colin Walters wrote:
> On Tue, 2012-10-23 at 07:26 +0200, Bastien Nocera wrote:
> 
> > I don't see how this helps. The code just lives somewhere that's still
> > within view (gnome-desktop isn't some magic module where things get
> > hidden), 
> 
> But I'm also volunteering to help keep it compiling and at least the
> systemd case tested.  You're *really* rejecting this based on the
> premise that the CK code would exist somewhere in GNOME and it's too
> much of a burden on you to ever even look at it?
> 
> At least Florian's reply earlier in the thread implied that he thought
> centralizing the logind/CK burden would be a good idea, and I'd take
> that to mean he would spend a bit of time helping out.
> 
> I just ran "git log gnome-settings-daemon/gnome-settings-session.c" in
> the gnome-3-6 branch.  You have *never modified this code*.  It's
> Richard, Rodrigo, Federico, and Matthias.  So I'm dubious about a claim
> that this code is so dire that you can't even be bothered to have a
> dependency containing it.

I didn't say the bug was dire. I said that it would need to be
maintained. As for the "I've never touched this code", I'm fairly
certain that I reviewed every change to it, which you can verify by
opening up the bugs referenced.

If this is the sort of thing you want to mention, we might want to
mention that I've committed more code to gnome-desktop than you have.
Did you really want to make this into a pissing contest? I'm not
Guybrush. And let's be clear, there's no maintainer for gnome-desktop.

> > gnome-settings-daemon's power plugin still requires logind to
> > work, 
> 
> Now in contrast to the "session is active" code, this is a complex
> codebase; 5000 lines is nothing to sneeze at.  Also, this bit is special
> to g-s-d, unlike the "session is active" bit which a number of other
> modules (gnome-shell e.g.) also need to query.
> 
> So it seems to me well within your rights as maintainer to say "only
> systemd is supported here".
> 
> > and gnome-shell with upower/ConsoleKit will likely behave brokenly
> > (given that there's no gnome-settings-daemon counter-part).
> 
> But the point is that we're not *regressing* anything for the CK case.
> Sure, GNOME in the CK case will have bugs.  That's fine by me.  GNOME
> has plenty of bugs, some of them even very embarrassing.
> 
> > What's the sudden attachment to ConsoleKit? You could just as easily 1)
> > port to g-s-d logind code to use D-Bus, and write a shim on top of
> > ConsoleKit that would export a similar API.
> 
> I took the previously working code.  It's not clear to me what benefit
> the changes you're talking about would provide other than turning
> compile-time detection into runtime detection, which is kind of useful
> but not of critical importance.

Two important benefits:
- the onus of updating/fixing/releasing the CK portion of code isn't
mine, or any of the other gnome-settings-daemon/gnome-control-center
developers. It's really a toss up between gnome-shell,
gnome-settings-daemon and gnome-session as to who would get the bugs
when CK behaves badly (or brings in other 
- I can use any API I want in the code using logind without having to
think about ConsoleKit, or thinking about having this exact same
conversation in 6 months.

> So what's the path forward in your eyes?  Are you still suggesting that
> GNOME immediately delete all CK code?
> 
> To be clear, my proposed plan is:
> 
> * Spend a little bit (not necessarily a lot) of effort to avoid
>   regressing CK.
> * It's OK if new features or bugfixes rely on logind.
> * If particular complex functionality like the g-s-d power plugin
>   gets too hard to map to both CK/logind, announce that in
>   advance, give a warning that code will be deleted, if no one steps
>   up to help, delete it.

If we keep on supporting CK, we'll be the ones getting the bug reports
about such and such part of the system being broken or badly behaving
because that configuration, we "support it, kind of, but not really".

You wanted something coherent, you'll end up with a box of ill-fitting
bits.

You still haven't answered why it's important to keep ConsoleKit. We're
giving 6 months headway to people that'll need to replace it, which,
from your code, should fairly trivial.