Re: [gdm-list] Branch update

[Brian Cameron <Brian Cameron Sun COM>]

Jon:

Thanks for the update, and for updating the Wiki about the new
GDM D-Bus rewrite.  It looks great.

> We've created a page on the wiki.
> http://live.gnome.org/GDM/NewDesign
>
> We've also started to list some of the things that need work:
> http://live.gnome.org/GDM/ToDo
>
> Feel free to write down ideas that you have.  Try to prefix ideas with
> your wiki name so we can keep things organized.

Yes, it would also be good if people could give feedback on whether
they are able to get the new GDM D-Bus branch working on their systems.
Over the past few weeks I have gotten it working on Solaris, and am
currently using it as my login program.  It's a bit annoying that you
can't currently select session and language, and that shutting down
and rebooting the system is not available.  However, I think these
things will be plugged back in the near future.  So hopefully this
will be a short-term annoyance.

> At this point I'd love to have some more people testing this out.  But
> I realize it isn't easy to test a new GDM.

If you are someone who has agreed to help with this, and if you are
having issues that are blocking you from making progress, then please
let us know.  For example, if you would like the code to get to a
certain point before you are comfortable starting your work, let us
know so we can focus on helping to get the code to the where you can
start helping.

Ray, Loic, Lucasz?  It would be good to get feedback from you about
your experience with the new branch and what you think about how
things are going, etc.

> We should also start to discuss what we should do with this branch.
> Obviously it won't be a branch forever.  Some possibilities include:
>
>   1. A new top-level gnome.org project (gdm, gdm3)
>   2. Replace / merge with trunk
>   3. A freedesktop.org project
>
> I don't really have any strong feelings.

To be honest, I don't either.  If other communities (e.g. KDE)
are enthusiastic about working together to create a single
display manager to rule them all, then I think option #3 would
be the best.  If not, then I have a slight preference towards
option #2.

I have cc:ed Oswald Buddenhagen, the KDM maintainer, to see
if he has any thoughts.

>  1. is probably fine.

The advantage is that this approach gives more freedom to break
interfaces, or at least a better defense when people complain about
them.  There would be less pressure to support all the features that
GDM currently supports.  That said, I'd bet quite a few GDM features
could get dropped without any notice (does anybody even use DMX
for example - does it even work?).

The disadvantage is that if this is a new module, then you'll need
to go through the module approval process.  Some people/distros may
not be as motivated to make a switch, or help participate in making
the new display manager meet their needs if the old GDM hangs around.
I'd imagine adoption would be slower taking this approach.  Perhaps
not a problem?

>  2. is probably less good since it really is so different and people
> may need to continue to use gdm2 for whatever reason.

I don't see this as a huge problem.  Unless we think the new design
is limiting in ways that would make it not support some important
features that users will likely require.

If we make the new D-Bus version GDM 2.21, then I plan to continue
maintaining, patching and releasing  GDM 2.20 with any fixes that people
in the community needs until the new D-Bus version of GDM reaches a
point that it is a suitable replacement.  This might mean that distros
might choose to not ship GDM 2.22 if it isn't functional enough to
meet their users needs.  Instead they could just stay using GDM 2.20
until they are ready to make the leap.

This might mean distros will need to get more involved to reimplement
features that are missing, and their users need.  Though, I don't
see this as a huge problem since most distros seem to already have
someone who is actively working on GDM anyway.

>  3. Would be interesting if we can entice other desktop projects into
> collaborating.  We could also use git which is arguably nicer for
> maintaining branches and doing merges.  However, we probably lose out
> on our translation team and stuff.

This is an idea worth exploring.  However, the existing "simple"
greeter has a lot of dependencies on the GNOME stack (such as
GConf & libglade for example).  Not sure if this would be a barrier
to getting other groups involved.  Probably not a significant one
since a "more simple" greeter or greeters using other widget sets
could be added.  It would be a good idea to ping the KDE community
to find out, I'd think.

> I'd like to have this somewhat decided by the time we start to release
> tarballs.  And that is coming right up...

I'd say that if we are going to release the D-Bus version of GDM
as GDM 2.21 that we need to get it to a reasonable shape that people
can actually use it for most needs.  I think the following features
are probably must have before we ship it as GDM 2.21 (assuming we
go with this approach):

- Ability to select language and session (sounds like this is close)
- Ability to use failsafe login session, so users can debug login
  problems and are not stuck if their system or user has a
  configuration issue.
- The ability to turn on accessibility should be available, if
  possible.  There will likely be a host of issues that affect
  accessibility users, so we should enable people who need a11y
  features to start testing and helping fix bugs as soon as we can.

That's probably not a huge amount of work to do in the next month
before the 2.19.1 release.  The following tasks would also be real
nice-to-haves to get fixed before a 2.19.1 release:

- Halt/Reboot from the GDM login screen would be a real nice to have.
  Mostly because people will complain if it is not there.
- auditing support would also be a real nice to have.

> So, please take a look at the code, build it, try running it and let
> us know what you think.  We really need your help.

I've shared my opinions, but I think we should make these decisions
by consensus.  I'm therefore interested to hear other people's opinions.

Brian