Re: [gdm-list] Branch update

[Brian Cameron <Brian Cameron Sun COM>]

Jon:

> > two things should be clear to you:
> > - i accept no regressions from current kdm
> > - the bulk of the work would be with you, at least for now
>
> I accept those conditions.  I appreciate you being forthright.  It
> sounds like we are all interested enough that we should at least give
> it a try - it can't hurt.  The redesign we've discussed here is at
> least different enough from both KDM and GDM to warrant a new project.

One issue that concerns me is with configuration.  Obviously people
have their systems currently configured to work with KDM or GDM, and
when we say "we acccept no regressions" does this mean that the new
display manager should work with whatever configuration the user has
previously set up with GDM and/or KDM, or is the assumption that users
distros will simply have to reconfigure the new display manager when
they make the switch?  I assume so, but we should probably be clear
about this.

> Unless there are serious objections, I'll go ahead and create a new
> freedesktop.org project for DisplayManager.  I'd love to be able to
> work together on this.

As I said in my previous email, I don't feel strongly about what we
should do here.  However, I am concerned about the implications about
creating another display manager.  I think we need to discuss these
implications before making a decision.  Also, few people from the
GDM community have really chimed in on discussions so far, so I
would appreciate getting more viewpoints about what we should do from
the community, and those that will be affected by these decisions.

The GDM 2.20 release has been a bit of work since quite a number
of bugs were introduced into the code due to the rewrite work that
has been done so far.  I think the most serious of these have
been addressed, but it wouldn't surprise me if more issues are found.
To what degree do you plan to continue being involved with GDM to
support these features and bug fixes that you have worked on in
the past?

If the new display manager is a different project, then I am unsure
how we should manage things going forward for GDM.  I'm sure people
in the free software community will continue providing enhancements
and bug fixes for GDM, and I'm not sure it makes sense to continue
not accepting them if the D-Bus display manager becomes a separate
module.

Competition is often good, and I'm therefore not opposed to there
being another display manager.  The concern though, is that there
will likely be fewer resources to focus on either one if we
create two.  Many distros might have users that depend on GDM
features that take some time to implement in the new display
manager, and don't we create a situation where some distros
will not be able to make the switch, or will have to support both
of them until all features their users require are supported by
the new display manager?

One advantage of keeping this work within GDM is it creates more
pressure for everyone to bite the bullet and get the new display
manager to support all needed features, and make a single
transition.  This could also be viewed as a disadvantage since
it might involve more pain to get things all working in a shorter
time-frame.

But I wonder if it might it make sense to get things right for GDM
users and then move towards making a freedesktop solution once we
know we've met the needs of GDM users?

So, before we make a decision on whether to create a new project,
I think we should, at the very least, discuss the ramifications
this has for GDM.  Does this mean that the new display manager will
support a different configuration mechanism than GDM?  Do we allow
GDM to further diverge from the D-Bus fork, or to what degree do
we tell people that GDM is frozen in time?

What do others in the community think about this?  Personally,
I'd prefer to not split my time between two projects, but I'm
happy to go along with community consensus.

Brian