Re: GDM and GNOME 2.24.

[Frederic Crozat <fcrozat mandriva com>]

Le mardi 12 août 2008 à 23:58 -0400, Matthias Clasen a écrit :
> On Wed, Aug 6, 2008 at 4:39 PM, Lucas Rocha <lucasr gnome org> wrote:
> > Hi Matthias,
> >
> > 2008/8/5 Matthias Clasen <matthias clasen gmail com>:
> >> On Mon, Aug 4, 2008 at 5:32 PM, Andre Klapper <ak-47 gmx net> wrote:
> >>> Hi GDM hackers,
> >>>
> >>> it's once again getting late in the release cycle, and GNOME 2.24 will
> >>> be released in 7 weeks. I see that a first GDM 2.23.x release has been
> >>> made available on July 31st to be able to test your code.
> >>>
> >>> Sebastien has published a list of issues and regressions at
> >>> http://mail.gnome.org/archives/gdm-list/2008-July/msg00028.html one week
> >>> ago.
> >>> The GNOME release team shares Sebastien's concerns.
> >>
> >> Too bad I wasn't around anymore on Sunday when this was discussed.
> >> I don't see things this way...
> >
> > Could you please share your point of view then?
> 
> Sorry, forgot to respond to this earlier.

I might regret this but I have the feeling something is wrong here.

First, I still don't understand why John is not responding to those
issues posted on gdm list. It shouldn't be your role to respond for him.

> So, going off Sebastiens list of issues,
> 
> > * no configuration migration from the previous version (ie people who
> > use gdm 2.20 and autologin should still have that activated after
> > upgrade)
> 
> I am not sure that is true, actually.
> 
> The new gdm uses the same config file location and format, and the
> same keys for autologin as the old gdm. I don't see offhand why the
> new gdm would not just pick up the options from the old gdm, but I
> have to admit that I haven't tested this. If it doesn't work, it
> should be an easy fix.

I checked wiki and some sections of the configuration file are not
handled :
-[security] : I'm not sure if it is supposed to be handled by
ConsoleKit/PolicyKit but there is no explanation how to handle the same
result as with the old gdm
-[gui] seems to be ignored / replaced by gconf (no migration help,
except for documentation key
-[greeter] is ignored
-[server] seems to be ignored (since it was used for multi head)
-[customcommand] is ignored.

> > * no graphical tool to change the configuration, autologin might be
> > available but how do you expect users to activate it?
> 
> This one I admit we haven't tackled yet, due to other things taking
> precedence. Our opinion on this is that login screen configuration
> needs to be handled in the larger context
> of user management. The solution for F9 was to turn on autologin by
> default where it makes the most sense (on the live cd), and explain
> how to set the option by (the horror!) editing a config file:
> http://live.gnome.org/GDM/2.22/Configuration
>
> One aspect of login screen configuration that we added in F10 is the
> ability to set the login screen background from the appearance capplet
> (under PolicyKit control).  Unfortunately,
> that patch hasn't found its way upstream yet, see
> http://bugzilla.gnome.org/show_bug.cgi?id=536531 .
> 
> Another aspect of login screen configuration that is handled in this
> way is power management settings, via a "Make Default" button on in
> the gpm preferences.

autologin is just one aspect of configuration. I've listed others above,
in the section about configuration files.

> > * no xdmcp option on the login screen
> 
> I have a really hard time seeing xdmcp support as a blocker. But if
> there is a strong need for this somewhere, it shouldn't be too hard to
> complete the chooser support that is present in the new gdm.

Why shouldn't it be a blocker ? If we want GNOME to be taken seriously
in corporate/university environment, we can't drop some part of XDMCP
support. 

> > * no graphical theme, I expect that's something users will complain
> > about but that's not really a blocker
> 
> Last I looked, the new gdm didn't have a text mode login, so
> 'graphical' may need some definition here.  If there is a strong
> desire for using the old impossibly-hard-to-get-right xml themes with
> the new gdm, then someone needs to write a greeter that supports this
> format.

This has been rehashed since the gdm came out : it drops support for xml
themes (which are used not only by distributions but also by users, just
look at
http://art.gnome.org/themes/gdm_greeter/?sort_by=date&limit=all&view=list&order=DESC ) and this format was also supported by KDM (there are two or three small differences but it is quite easy to port a XML theme from gdm to kdm and vice-versa) and the only response people got was : "someone needs to write a greeter to support the old format". Well, I don't remember anybody asking for a gdm rewrite, neither for those regressions..


> > * would be nice to have an updated documentation
> 
> Certainly.  http://live.gnome.org/GDM/2.22/Configuration contains a
> lot of the information that will be needed.

When we are talking about documentation, we are talking about
documentation IN gdm tarball, not a website. I have to confess Brian
requirement to only accept patches adding new features when they had
updating documentation 

> > * the lack of support for multidisplay configuration might also be an
> > issue for some of the ubuntu users
> 
> This needs clarification.  If it refers to multi-display as multiple X
> servers, then we probably should discuss some use cases first. If it
> refers to multihead as in Xrandr,
> then yes, we do want to improve the handling of that in the login
> session, hopefully in time for 2.24.

Well, Brian has talked about it over and over (for SunRay for his
specific case) on gdm mailing list.

> The rest of the items on Sebastiens list were just Ubuntu integration
> issues as far as I can tell.

Distributions are important and not making their jobs harder would be
nice.

Sorry if this mail sounds harsh, but I really think we are seeing
regressions in gdm (and gnome-session is starting to show the exact same
"coup d'etat" or "fait accompli" pattern) being treated as "not
important" because there is some sort of agenda (I'm not sure if it is
"fast user switching") being pushed with small consideration to people
(or even module co-maintainers) input and fixing those regressions
doesn't seem to fit in this agenda. I hope to be prove wrong on this.

-- 
Frederic Crozat <fcrozat mandriva com>
Mandriva