Re: [gdm-list] Branch update

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

Hi Brian,

On 10/4/07, Brian Cameron <Brian Cameron sun com> wrote:
...
> 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

Yeah, moving to a freedesktop hosted project may be biting off a bit
too much to chew, for now.

I've also been convinced by your argument that we don't want to have
to support two different projects.  Furthermore, in order to get the
new code polished and tested properly we need to focus everyone's
attention on it.  So, if we want the new work to progress as rapidly
as possible we should do everything in our power to make it hard to
continue to use and support the old code.

That said, we also need to make it clear that this is a fresh start.
Not everything that was supported in the old code will be supported in
the new, and things may work differently.  We also need to make sure
that we maintain a high quality and stay true to our design goals.

I don't think doing a gdm-classic branch at this this point is
necessary.  We should simply make a stable branch for 2.20.

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

In order to focus our efforts I think it is important that we
establish, up front, that after the standard 2.20.x point releases the
2.20 branch will - not be supported.

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

Actually, you've convinced me that supporting two different
branches/projects is not a good idea.

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

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

So, the above are all really about maintainership and making the tough
calls about features.  A touchy subject I'm sure.  Let's get it out on
the table.

As I said to you at GUADEC I think you have done a fine job
maintaining GDM.  It arguably the hardest module to maintain - due in
part to the nature of the code and the myriad of supported
configurations.  So, that is a tribute to you.

I would love it if you could continue to perform most of the important
maintainer duties with the new code.  However, as the primary author I
would like to have the final say on what goes into the code.  I think
this is basically how our workflow has evolved for the branch.

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

That would be awesome!  This is one area where I would love for you to
take the lead.  I will be spending most of my time working on getting
the code up to snuff.


So to summarize, my proposal:

Let's:
 * Branch for 2.20.
 * Delete everything from trunk.  I mean everything.
 * In a separate operation move everything from the branch into trunk.
 * Add both of our names to MAINTAINERS
  * Share maintainership duties
      - you take lead in all aspects of releases
      - you take lead in security and interface analysis
      - you lead organizing the documentation team
      - you lead working with the translation teams
      - you lead all aspects of Solaris support
      - I will devote most of my time to hacking on the core design
      - I will have final say over changes to core code (as primary author)
      - I will delegate this responsibility as necessary

I think this is close the optimal distribution of responsibilities.

Does this sound reasonable?  If so, then let's do it.

Jon