Re: [gdm-list] Branch update

["William Jon McCann" <mccann jhu edu>]

Hi Brian,

On 10/4/07, Brian Cameron <Brian Cameron sun com> wrote:
>
> Jon:
>
> > So I have a few concerns about replacing gdm2 trunk at this point.
> > Some of these are:
> >
> >  * I can't be 100% sure that we'll be ready for 2.22.
> >    I'm certainly going to try.  But due to a new job and some family
> > stuff I can't be sure.  I also haven't had much buy in / help from any
> > other developers yet.
>
> I have felt that I have been encouraging about the work you have done so
> far in making redesign changes to GDM 2.20, and I feel I have also been
> encouraging about working with you to make the redesigned branch the
> next 2.21 release?  I've also done a fair bit of work in the stable
> branch fixing bugs that were introduced by rewrite efforts so far, and
> work to get ConsoleKit and the new GDM branch working on Solaris.  I'm
> disappointed that this isn't considered much buy in or help.  If there
> are issues, lets talk about them.

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. ;)

> 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.

> Also, I don't think anyone was suggesting that you do all the work.
> I'm sure that if these changes go into SVN head that people in the
> community will help to make the needed changes to make GDM work as
> needed.  Or do people think I am being to optimistic?

Hard to tell.

> >   * 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.

> >   * We may want to do branches again and SVN just sucks at merging.
> > (I'm not a git fanboy either)
> >
> >  * There really isn't any history for most of the files in the branch
> > since they are all new
> >    And I wasn't even using ChangeLog entries for the first month or two.
>
> I'm not opposed to some lack of comments in the ChangeLog considering
> the effort involved in this rewrite.  I'd be happy to just merge what
> ChangeLog entries that have been made in the branch to head.
>
> 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
b) overestimating our ability to perform any kind of merging

> >  * Understanding the copyright ownership becomes a great deal more difficult.
> >    There is arguably some real value to starting a fresh repository
> > with new files and understanding who owns the copyright.  And
> > specifically not owned by a Queen.
>
> Wouldn't copyright be an issue anyway?  Although you've rewritten a
> bunch of the code, I'm a bit surprised to hear that you rewrote
> everything.  Just creating a new module with new files doesn't
> change copyright ownership issues.

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

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

> Geroge Lebl is responsible for the Queen copyright, and he wrote a lot
> of GDM code.  Making sure we rewrite everything he contributed seems a
> bit much to try and accomplish in a 2.22 timeframe.  It might be easier
> to just ask George if he'd be willing to change how the code he
> contributed is copyrighted if this is a concern.  I'd recommend at
> least talking with him about this before spending a lot of time trying
> to purge his contributions from the source.

I'm fairly certain that most are already gone.  At some point we
should do a careful analysis.

> I think the reason for the Queen copyright and other oddities in GDM
> (such as the easter egg you can find if you type "start dancing" or
> "stop dancing" into the gdmlogin greeter were created because George
> wanted GDM to be a fun project to work on.  I've tried to maintain
> George's colorful encouragements, but I'm not particularly attached
> to them.

Well good, they're all gone.  :)  A joke is only funny so long.

> >   * We will need a XDG D-Bus API for DisplayManagers and my previous
> > experience with trying to work on this is that it is near impossible
> > without a single reference implementation.
> >
> >   * GDM isn't really part of a desktop.  And I expect that
> > DisplayManager will be moving even lower in the stack (or at least
> > earlier in startup).  Moving it out of gnome.org may help avoid the
> > perception that it is a desktop component.  It is becoming very
> > tightly integrated with ConsoleKit, HAL, and PolicyKit - all
> > freedesktop components.
>
> I agree that it makes sense, long-term, for a rewritten GDM to move
> into FreeDesktop and to become de-coupled with GNOME.
>
> I'm not questioning whether this is a good idea, only how it happens.
> Does it need to happen now, creating a separate project?  Or can we get
> GDM working again with these new interfaces, and then address copyright
> issues and moving to freedesktop over time?

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.

Jon