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

On Wed, 2012-10-24 at 10:11 +0200, Bastien Nocera wrote:
> And let's be clear, there's no maintainer for gnome-desktop.

I do look at incoming bugs and review patches, though since the module
is a bit of a grab bag, for things like randr I'll toss reviews of those
bits to Federico if he wasn't the original author.

> - 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 

No disagreement, this is an ongoing burden.

> - 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.

And for the project in general, dropping out a whole column from the
test matrix (gnome-shell with CK, fallback mode with systemd) is indeed
a notable win.

> 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. 

Because I'm opposing your methods here on *general principle*.   I don't
care about ConsoleKit (the codebase) much at all.  What I do care about
is when I go to GUADEC and hang out with some of the Debian or Ubuntu
people who rely on CK, we have a sense that we're part of a shared

I'm all for making GNOME+systemd kick ass.  But not at the cost of
giving up the "rough consensus and working code" aspect that forms GNOME
and other FOSS projects.

Your process here was to post on a Friday that you were going to delete
the code, have a lot of feedback even over the weekend, then on Monday
*do it anyways*.  That's just not the way we should approach problems in

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]