Sherry: > The Fast Reboot project team believes and has suggested that the > simplest way from its perspective (without the new SMF framework) is to > augment ConsoleKit and associated D-bus messaging system. The Fast > Reboot project team understands the GDM team's concern regarding having > to maintain Solaris specific code, and believes that
I am not really the "GDM team". I work on the Desktop team, which includes GDM and ConsoleKit. Several people on the Desktop team work on these modules. Not meaning to nit-pick, but just to clarify. > 1. there is already a solaris specific directory to accommodate > Solaris specific changes so the addition should fit well within > the existing framework; I never suggested that it is inappropriate to add Solaris-specific code to ConsoleKit. As you say, it does already contain some Solaris-specific code. > 2. if we are unwilling to do so we will forever be constrained > by what the other operating systems have already done. Forever? That is a long time. My suggestion was that before we move forward, it would be best for someone knowledgable of the requirements to first start a discussion with the external ConsoleKit community to determine the best way to integrate this feature. We are free to hack ConsoleKit to add Solaris-specific features if we want. That is our freedom since it is free software. However, making that choice without first having a discussion with the external community seems very poor engineering to me. For example, we might find that solving this problem with the external community is no more work than solving the problem in a Solaris-specific manner. Or we might find others in the external community interested in helping with some of the work. If these sorts of things are the case, then it would be foolish to not take advantage of working with the external community in an open manner, rather than maintaining our own Solaris-specific patches to the code. Really, if we are not interested in working with the upstream community then I wonder why we want to use ConsoleKit for this feature in the first place. If we want a home-brewed solution, then we should write a home-brewed solution. If we want to use ConsoleKit, we should work with the ConsoleKit community. > The Fast Reboot project team could send mail to the suggested alias > ConsoleKit at lists.freedesktop.org > but since the Fast Reboot project team has only kernel developers, the > team is not sure how to act upon whatever suggestions the community > offers, ie, the Fast Reboot project team cannot determine whether the > suggestions are feasible due to the intricate relationships among GDM, > D-bus and ConsoleKit, and even if it can, it cannot commit the GDM team > to or not to adopt any of the suggestions, To me, the above seems a poor reason to not have a discussion. Having such a discussion does not commit ourselves to doing any specific work, nor does it prevent us from "doing our own thing" if that is what we decide to do. But not having such a discussion means that we are designing the code blind. Myself and other members of the Sun desktop team who work most closely with GDM and ConsoleKit are already on the ConsoleKit at lists.freedesktop.org mailing list, and I am sure myself and others would help to facilitate any discussion started there. Really this is an opportunity for the Desktop and Power Management teams to work together in an open forum. To me, this sounds like a great way to collaborate together and with others. Also, I do not think the Desktop team will have any problem assisting with any needed coding. Obviously, the Desktop team is very eager to see shutdown and reboot features working better. > I'd suggest that this is how we should proceed: > > 1. Put the case in "waiting for spec" state > > 2. Sherry's team to work with Brian's team to > (a) identify individuals that need to be involved > (b) task engineers to experiment with the proposal(s) > (c) once we have a proposal that both teams can semi-agree upon, > contact the community aliases (GDM and ConsoleKit) to seek > approval if such approval is deemed necessary. > (d) come back to LSARC with the spec and continue Personally, I do not see the harm in engaging the external ConsoleKit project more early - even if just to give a heads up that this is an area we plan to work on. We might find there are others in the external community who might help, or who have already been thinking about or designing a solution. Their input would, I think, be valuable in putting together a proposal. Brian
