LSARC: As some of you may be aware, the GDM display manager is undergoing a rewrite.
http://live.gnome.org/GDM/NewDesign In many regards, this rewrite is long-overdue. The design of GDM has not changed significantly in over 5 years, and the new rewrite is making use of newer and better design, such as GObjects and D-Bus for inter-process communication. There are also plans afoot to make GDM better integrate with GNOME overall, in terms of theming and look-and-feel. Other benefits are detailed at the above link. On the downside, the configuration system of this new GDM is being reworked. While it is too early to tell exactly what the impact will be, I anticipate that the configuration mechanisms will be incompatible with the current GDM. I believe this is an issue we need to think about because GDM's current configuration mechanisms were declared as Stable (Committed) in LSARC 2005/734. At the time of LSARC 2005/734, there was no visibility that the configuration would ever change, and the decision to make them Stable seemed sensible at the time since login configuration isn't the sort of thing that we want users to rework unless necessary. That said, breaking GDM's configuration stability might not be so serious. I say this because GDM has never been the default login program on Solaris. It has primarily been available for users with accessibility needs, so they can have a workable alternative they can switch to. Though it is also used by some people who simply like GDM over CDE login. Since GDM is not the default login program, any interface breakage will likely not impact a great number of users. Also, the interfaces have only been declared as Stable/Committed in Nevada (not in Solaris 10), so there has not yet been a supported Solaris release that contains these interfaces marked as Committed. Though, the upcoming Indiana release may change that (though I'm not sure whether Indiana carries the same interface stability requirements as, say, Solaris 10). The new GDM rewrite will not be released until GDM 2.24 at the earliest, and (probably more realistically) won't be ready for use on Solaris until GDM 2.26. Since GDM 2.24 won't be released for about 7 months, and 2.26 for about 13 months, that gives us some time to figure out the best way to deal with these interface changes. I can imagine a few options we can consider (or perhaps a combination of them): + We could EOF/EOL the existing GDM configuration interfaces, so that we can replace it with the new GDM in a year's time. As I state above, this fits in well with the expected time it will be ready for use on Solaris. + We could ensure that there is configuration migration from the old GDM to the new GDM. I am pretty sure that there will not be a 1-to-1 mapping of configuration options, so it is unlikely that all user configuration would migrate, but we could likely make sure that the most important (e.g. security related) options do migrate. + We could continue shipping the existing GDM 2.20 and also ship the new GDM in parallel, allowing the user to pick which one they want to use. + Other ideas? I know that the CDE is in the process of being EOL/EOF (LSARC 2007/648), but I think we should hold-off on removing CDE login as the default login program until the new GDM rewrite is ready to replace it. Since it will likely be some time before Sparc is ported to Xorg, I do not think it would be possible to switch to using GDM as the default login program in the near term anyway. Note that for GDM to be the default login program, we have to use Xorg since it supports VT (Virtual Terminal) switching while Xsun does not. This is required to allow users to switch to "console login". Obviously, this should not impact the EOL/EOF of the other CDE components. I am interested to hear what ARC thinks the best approach should be. I wanted to raise this issue early so that we could consider the EOF/EOL process if that is most appropriate. Thanks, Brian
