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

[William Jon McCann <william jon mccann gmail com>]

On Wed, Oct 24, 2012 at 8:47 AM, Colin Walters <walters verbum org> wrote:
> On Wed, 2012-10-24 at 10:11 +0200, Bastien Nocera wrote:
...
>> 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
> project.
>
> 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.

What this should mean, to me, is that we are all working toward the
same goals. What are those goals? They are perhaps best found by
considering "what does the user see?"

http://blog.fishsoup.net/2011/03/11/what-does-the-user-see/

The code serves that purpose and that purpose alone.

I wrote ConsoleKit. I wrote it for GNOME. I wrote it because we needed
it to get fast user switching working in gnome-screensaver, we needed
it for sane device support I was working on for Rhythmbox, I worked
with David to make sure it fit the needs of HAL, which was needed to
get the device support right for Nautilus. In my first analysis of the
problem I concluded it was something the OS should have been doing all
along and really ought to have been part of the kernel or very low
level userspace. I had started to investigate creating a new init
system that would have a more modern process group / session leader
concept included. At about the same time, Upstart started. The project
seemed promising and I changed my strategy. ConsoleKit was a stop-gap
measure. Just enough working code to do the job we needed, and only
the job we needed, at the time.

But now we have different needs. And something entirely better has
come along. So, I no longer maintain or support the use of ConsoleKit.
I handed ConsoleKit off to Lennart. To do as he saw fit.

I agree with you that it is wrong to arbitrarily remove code from our
core system. That kind of churn is disruptive. It must be motivated by
a need. It should be motivated by what the user will see. And what
experiences we want to provide.

It is. We have designs on the table that motivate the use of systemd.
There are a number of them (some more subtle) but I'll just mention
just two:
https://live.gnome.org/Design/Apps/SystemLog
https://live.gnome.org/GnomeOS/Design/Whiteboards/ProblemReporting

The first one mostly uses the journal directly but the second uses the
journal and probably systemd core to handle some of the response to
application misbehavior.

In addition, we also have had long standing plans to improve the way
we start and manage the session services. I was one of the main
contributors to the current gnome-session. I was clear during that
rewrite that it too was a stop-gap solution. The difficulties there
were quite similar to the start and management of system services. I
investigated logind at the time and decided we should just do
something that solved the immediate need and wait for a more complete
solution. We have one. Systemd can already do this I'm told.

It is motivated by the user experience. Faster start up, more robust
failure detection, better diagnostic information during failures,
consistent tools, etc.

I agree with you that we need to have a motive to change and that
costs should be weighed carefully. We can make the case.

What is unwise, in my opinion, is ifdef'ing or branching the user
experience to suit the code.

I don't think it is useful to even discuss whether we should remove
ConsoleKit or not. We must. It is on life support. If we are still
able to move forward with the user experience changes we need to make
while maintaining some compatibility - fine. But we need to have an
end game. This is a lesson we have learned over and over. Let's not
make the same mistakes again.

I think it would be in the interest of all parties to have the
conversation about why some are unwilling to use the best components
available today to allow us to go forward and make the user experience
as good as it can be. That is the best kind of rough consensus and
working code. The one that matters for what the user sees.

Thanks,
Jon