Re: [gdm-list] GDM status

[Brian Cameron <Brian Cameron Sun COM>]

Jon/Vincent:

Thanks for the update, Jon.

First of all, I want to say that I think Jon has done an amazing job
of putting together a new display manager which uses the more robust
D-Bus and GObject interfaces.  Considering that Jon has completely
rewritten GDM, I am impressed by how far along the project is at this
time.  I believe that, in the long run, a display manager based on these
technologies will be more maintainable and more functional.  A GDM
rewrite has been long overdue.

If the regressions that Jon highlights are addressed, then I think the
new GDM will do a good job of meeting the needs of the common-case GDM
user.  By common-caes, I mean the normal desktop user who typically
does not significantly modify the GDM configuration.

That said, I have some concerns that I think would benefit from
release-team guidance.

1) The GDM project has a long history of keeping its interfaces
   stable and backwards-compatible.  Starting with GDM 2.14, the GDM
   made this more formal by declaring its configuration mechanisms as
   Stable in the documentation.  Refer here:

   http://www.gnome.org/projects/gdm/docs/2.14/overview.html#stability

   Since many GDM configuration options affect system security, it
   seemed appropriate to ensure users that their settings would be
   supported in a stable fashion.  However, in hindsight, perhaps
   these promises were made inappropriately.  Until the 2.21 release
   cycle, there was no reason to believe that such efforts to keep GDM
   configuration stable would ever be abandoned.

   It is not clear to me what the exact plans for addressing GDM
   interface stability are going forward.  At any rate, the existing
   rewrite does not use the same configuration mechanisms, nor is there
   any way to automatically migrate the user's configuration to the
   new GDM.  I am not sure there is time to address these concerns in
   a GDM 2.22 timeframe.  Nor am I sure what the best way to address
   these issues should be.

   I realize the GNOME community doesn't have any formal policies
   regarding interface stability in Desktop components.  However,
   I think some release-team guidance would be useful to figure
   out how to manage this, and send the right message and expectations
   to users.  I imagine some users will find it confusing that past
   documentation declares these interfaces to be Stable unless we
   communicate the right message to them.

   I can imagine a few ways to deal with this that would probably
   be more appropriate than silently breaking interfaces.

   - Release the new GDM as 3.0 to make it more clear that interfaces
     have changed in an incompatible way.
   - Make the new GDM parallel installable with the old GDM so users
     who depend on the old features can continue to use them
   - If the new display manager rewrite does not intend to support
     the interfaces in a stable manner, perhaps it should be
     released as a separate project, and not as GDM.
   - Perhaps the GDM rewrite should honor the old configuration
     mechanisms or provide some automatic migration.

   Perhaps the release-team could advise what makes the most sense
   for the GDM project?

   If the decision is that it is acceptable to break interface
   stability, then does the release-team have any recommendations
   about how this should be communicated and documented to the
   user?  Is bumping the version to 3.0 sufficient, for example?

2) Historically GDM has had fairly complete user documentation, while
   the new rewrite lacks any.  Considering that the configuration
   mechanisms are changing, I suspect many users will find switching
   to the new GDM difficult without some documentation that, at the
   very least, explains how to configure the new GDM as needed.

3) While the GDM rewrite does a good job of meeting the needs of
   common-case users, it does not support many advanced configuration
   options.  There is some debate about which configuration options
   make sense to support and which should be deprecated.  However,
   I suspect that users with novel configurations (e.g. multi-display,
   Xinerama, terminal server, etc.) will find the rewrite lacks
   configuration features that they depend upon.

   For a specific example, the old GDM allowed users to configure
   different Xserver commands per-display, while the new GDM hardcodes a
   single Xserver command for all displays directly into the binary.
   Those who use the new GDM will need to recompile GDM to change the
   Xserver command to a non-default value at all.

   It is hard to predict which configuration options are really
   important or needed, but I suspect there are a fair number of users
   who will find the new GDM does not meet their needs.

> We are going to move forward and continue to fix these regressions.
> And Fedora still plans to ship this new GDM in the next release.

Since it sounds like Fedora is planning to use the new GDM regardless of
whether it will be approved by the general GNOME community, I think this
will provide useful insight on what areas needs work.

However, I think distros should be careful to ensure the new GDM meets
the needs of their users before switching.

I think the release-team is aware that I am fairly conservative about
interface stability.  If the release-team or the general GNOME community
doesn't feel that these issues are important, then I understand.  I
will defer to whatever decisions the release-team and Jon make in this
area.  I just wanted to raise the issues and provide another perspective
on the status of the rewrite.

Brian