Re: [gdm-list] Branch update

[Brian Cameron <Brian Cameron Sun COM>]

Jon:

> I certainly appreciate those efforts.  I didn't mean to offend you.
> I'm sorry if I did.  I was merely trying to explain there is still a
> bit of heavy lifting left and at the current pace... and you know
> buses just whiz by me and stuff. ;)

No, I am not offended at all.  I just wanted to express that you have
my buy-in, for what that's worth.

What might make sense is for us to do the following:

- Create a new branch based on SVN head.  This could be called
  something like gdm-classic
- Move the mccann-gobject branch to SVN head

Then, we can do releases on both branches for GNOME 2.22.  Distros
can decide for themselves which one they want to ship, and this allows
people to get more involved with the new D-Bus display manager code
right away.

We can continue and do the same for 2.24 and so on until everybody has
migrated to the new display manager.  Would this address your valid
concerns for now?

We can always decide later to move the D-Bus GDM to a separate module
and replace SVN head with the "classic" code at a later date if this
turns out to be unworkable.

Or do people have better suggestions?

> > I don't think it would be the end of the world if GDM doesn't have
> > a 2.22 release or if the 2.22 release is late if we don't get things
> > all together in time.  We can only strive to do our best.
>
> I guess that is true.  But one of the problems is that I *do* want to
> start making release.  As soon as possible, in fact.  There are may
> reasons why is very difficult to try to replace a stable, and mature
> product with a completely new one.  Expectations and perceptions
> mostly... but still difficult.

Indeed.  If we decide to release the D-Bus display manager as GDM, then
I think this does mean that efforts must be made to support the existing
GDM configuration to a reasonable degree.  I'm flexible about dropping
support for configuration options that are of questionable value (e.g.
whether asterisks or circles appear as the password character), and am
agreeable to deprecating configuration options that no longer apply
(gdmgreeter options if we deprecate gdmgreeter, for example).

I'd recommend that we plug back in all configuration options that we
think make the most sense and wait for bug reports to see what other
options people the community thinks we need to add back.  If there is
reasonable demand, I think we should respect that.

At a later date/release, we can think about redesigning the
configuration system further.  This is probably a significant bit of
work in its own right, especially if we want to figure out a system
that would allow GDM and KDM to share a common daemon.

> > >   * It may be very difficult to merge / replace trunk with an entirely
> > > new branch (but with some files using the same name) using SVN.
> > >    Haven't tried but it scares me.
> > I think it would make more sense to just replace the existing head
> > files with the new files.  For the time being we could create an "old"
> > directory to move code that aren't supported for the time-being
> > such as gdmgreeter, gdmlogin, gdmsetup.
>
> To be honest, this sounds terrible to me.  And is one of the things
> I'm concerned about.  The way it would work is that anything different
> from what we have now will be considered a bug or incomplete.  That
> isn't the way I've been thinking about and designing the new code.

I'm not opposed to introducing bugs as long as we agree that our goals
are to support the needs of our users, and will work with people to
add back lost features where there is a reasonable need.

Are there particular features that GDM currently supports that you
feel that you would simply not be willing to entertain in a rewritten
GDM, even if someone else were to provide a reasonable well-written
patch?

Do you feel that you would not want to support a platform or an
interface that a distro requires because it would involve introducing
an ugly #ifdef or two into the code?

As an example, the Face Browser only makes sense with certain PAM
configurations.  Do you foresee that the D-Bus version of GDM would not
allow users to configure whether the face browser is on or off?  Or do
you imagine it will only be used by people who have PAM configured
in ways where the Face Browser makes sense for user selection?

As another example, if someone out there wanted to port gdmgreeter
(and related configuration options) to the new branch and provided
a patch, would we reject it just because we don't like gdmgreeter
anymore?

Just to throw some discussion points out there so I can get a better
feeling of whether we are on the same page or not.

> > I know that there have been some fixes that have gone into SVN head
> > since the fork that will get broken again if we do this.  That's okay,
> > people will just need to get involved and fix those bugs again if
> > they are still present.
>
> I'm afraid that you are:
> a) greatly underestimating the difference between the branch and trunk

It's also easy to underestimate the impact of having two competing
display managers.  While everybody might now say we don't care about
issues like configuration stability, there may be a different tune
if and when significant users/customers start to complain that they
can no longer function with the new display manager for whatever
reason.

> b) overestimating our ability to perform any kind of merging

You say below that the code has been practically rewritten.  If all the
code is new, how much merging is really needed?

> > >  * Understanding the copyright ownership becomes a great deal more difficult.
> > >    There is arguably some real value to starting a fresh repository
>
> Yes, with very few exceptions (that I've been trying to keep track of)
> everything has been:
>  a) from a known contributor (Ray for example)
>  b) copied from a project with a well understood history and
> compatible license (D-Bus/glib)
>  c) completely rewritten

I noticed you deleted all the docs from the old branch, which is another
area where older stuff is probably lurking around.  The docs probably
need rewritten anyway.  I've written much of the docs, so if there are
parts that are still useful, then those bits can still be used.  I don't
need my contributions to be associated with any Queens.

> The exceptions are few:
>   common/gdm-common-unknown-origin.c
>   daemon/auth.c
>  small bit of daemon/main.c
>   some parts of daemon/gdm-xdmcp-display-factory.c

I'm impressed.  I'm not sure what our plans for gdmsetup are.  If we end
up adding that back, it probably contains a fair bit of older code.
Likewise for gdmgreeter.

Though, I'm not sure it would have to be a problem if various optional
subcomponents like gdmgreeter were to have a different copyright than
the rest of the code.  They could even be moved to a separate module if
we wanted to keep them around and copyright were an issue.

> Well it has to go somewhere - now.  And I think there are some pretty
> compelling reasons to avoid clobbering the current gdm2 trunk... so, I
> don't know.

I agree.  I don't think we should clobber anything, just manage with
branches.

Brian