Andre:
This question seems to have created a lot of FUD, and I wanted to try and give a more clear perspective on the situation. As the maintainer of GDM for the past several years, I feel I have a good understanding of the needs of GDM users, and what will cause issues. First of all, I don't think that the loss of gdmgreeter or the GDM themes is a real issue. Some users will find it annoying that their favorite theme can't be used, but if there is enough interest in supporting such themes long-term, then we can imagine such users will push for it to be rewritten to use the new infrastructure. This probably isn't a huge amount of work. The old greeter just needs to be updated to use a different IPC mechanism. However, there are a few design issues that probably would need to be considered. Session and language choosing has changed in the new GDM, so it might make sense to revamp things like this when porting the old greeter. Also making it GObjectified is perhaps a bit of effort. Users who really love the old theming can probably just continue using GDM 2.20 if they want. Such users probably are geeky and would know how to replace or rebuild a module. Secondly, I do not think the loss of gdmsetup is that big of a deal. Most configuration options in GDM can now be configured via gconf-editor. There are still a few daemon configuration options in /etc/gdm/custom.conf, but not the ones users typically want to modify (except for perhaps automatic/timed login). I think that people can probably live with using gconf-editor and their favorite ASCII file editor for updating the configuration for now. The old gdmsetup program had a real security flaw in that it needed root permissions to run. It would be better if the GUI ran as the "gdm" user. So it needs a rewrite anyway. That said, I think the two issues that are of real concern are the fact that the new GDM does not support managing multiple displays when each display has its own graphic card. The second issue is that you can't run the XDMCP chooser from the login GUI. The need to manage multiple displays is commonly used in terminal server environments. Distros who want to support terminal server setups out of the box simply can't consider the new GDM. It is probably reasonable to expect this regression could be fixed by GDM 2.26. At any rate, until it is fixed some distros, like Sun, will not be able to include the new GDM. I imagine some other distros that need to support terminal server environments will likewise stick with GDM 2.20 until this regression is addressed. Since this is an important feature for many users, I can't imagine this regression will be broken for long. Users who want to be on the bleeding edge could try to support multiple server environments using the GDM patch that makes gdmdynamic work with the new GDM: http://bugzilla.gnome.org/show_bug.cgi?id=536355 Using GDM built with this patch, you could add multiple displays via scripting rather than hardcoding the displays in the configuration file. Using this sort of technique, you could do some interesting things, like if HAL detects a hotplugged display, you can manage or unmanage the display on the fly by just calling gdmdynamic. The fact that you can not run the XDMCP chooser from the login GUI anymore is the other problem. That said, XDMCP is crufty and insecure, so it might be reasonable to take the stance that it is now a second class citizen and regressions are okay in this area. However, I believe there are enough XDMCP users out there that I also can't imagine this regression will be broken for long. I am not aware of any other regressions that I think are particularly serious. Now that the documentation is mostly put together, and there is some reasonable configuration migration support since the new GDM still supports the /etc/gdm/custom.conf file for options which make sense; I think GDM is in much better shape than it was a few weeks ago. While these are just my opinions, I think that it is reasonable for the release team to bless the new GDM with the understanding that some distros won't update until some of the more important regressions are addressed. The new GDM is appropriate for use on distros where the intended audience isn't likely to want to run complicated setups like terminal servers. Most distros that ship the new GDM would likely also make available RPM's/binaries/whatever for the old GDM, so that users who have such needs can backport to the old GDM for these regressed features. Or, I could also understand if the release team felt that GDM needs a bit more polish before its ready to go out the door. I would think another release cycle would get us that much closer to addressing the more serious regressions. It's really the release team's decision at this point. I don't think there is enough time to address these remaining regressions in this release cycle. The design considerations regarding how ConsoleKit and GDM should interact regarding supporting multiple displays hasn't been figured out in enough detail yet. Brian
the release-team normally asks on d-d-l for comments on new modules and dependencies. In this case I'd like to ask for valuable feedback on gdm trunk. Among the release-team there are different opinions whether to use trunk or 2.20.x for GNOME 2.24 and hence different opinions on regressions (and the definition of that term) and missing or rewritten functionality. As far as I know, Fedora and Foresight ship trunk, while Ubuntu and Mandriva tend to ship 2.20.x. Opensuse releases in December so no real use in asking them. No idea about Debian. Don't know if providing links to former discussion threads might influence opinions. Feel free to ignore these links and to share your own non-influenced experience instead: http://mail.gnome.org/archives/release-team/2008-August/msg00021.html http://mail.gnome.org/archives/gdm-list/2008-July/msg00028.html http://mail.gnome.org/archives/release-team/2008-August/msg00072.html We'd like to have a decision made by this weekend so there's two weeks left for translators. Comments highly welcome, so you can't blame release-team only in the end. ;-) andre
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
