Re: [gdm-list] Branch update

[Brian Cameron <Brian Cameron Sun COM>]

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

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?

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

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

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

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

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

Brian