On Wed, Oct 24, 2012 at 8:47 AM, Colin Walters <[email protected]> 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 _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
