Re: [gdm-list] Branch update

[Brian Cameron <Brian Cameron Sun COM>]

Jon:

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

If we haven't bit off a bit much to chew already.  :)

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

I agree.

> 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 think we need to carefully address this in the release announcements
for 2.21.  We need to make clear that people/distros with strong
stability needs should probably stick to using GDM 2.20 until they are
comfortable that the new GDM meets their needs.

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

That is fine for me also.  If a need for a "classic" branch becomes
apparent in the future, we can consider that later and base it off the
gnome-2-20 branch.

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

Right, although I plan to continue accepting patches to fix bugs
and continue making 2.20 dot releases to allow people access to such
bug fixes on a reasonable schedule.  This may mean that 2.20 dot
releases may continue past the normal schedule.  I'd say 2.20 will
be supported for bug fixes only, and no future GDM release will
be based on the GDM 2.20 or earlier code.

I do not plan on accepting any new enhancements into 2.20.

[...]

> 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 am not sure I agree that GDM is the hardest module to maintain, but
thanks for the kind words.

I'm flexible about how we move forward with maintaining GDM.  I am also
comfortable with you being an official co-maintainer of the GDM head
branch.

For the time being, I am comfortable with providing patches to you
for approval rather than committing changes myself.  While the code
is still under development, it makes sense for one person to be in
control of how changes are made.  And it makes sense for that person
to be you.

As maintainer, I've always tried to defer to community consensus rather
than thinking that any one person has "the final word".  I'd prefer if
we follow a process in situations where there is disagreement between
the maintainers and/or other engineers who have made significant 
contributions to GDM.

I think such disagreements should be brought up in this gdm-list public
forum and discussed.  I think the various stakeholders should make an
effort to come to a reasonable agreement that meets needs without
negatively impacting the code or design.  I think this is basically
how I've tried to manage GDM to date.

Having said that, I think that based on your contributions to the
code that your opinion would be valued with more authority than the
opinions of others.  But I would hope that if we enter a situation
where everybody other than yourself wanted GDM to move in a certain
direction that you wouldn't be completely inflexible or resistant
to compromise.

Does this seem reasonable?

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

I'm happy to take the lead with the documentation.  It's an area where I
have tried to add value to the GDM project, and I would like to make
sure that the documentation remains of reasonable quality.

That said, I'll probably need help from you to document the aspects of
the code that you know best, such as how everything works with D-Bus.

> So to summarize, my proposal:
>
> Let's:
>  * Branch for 2.20.

The 2.20 branch is already created.

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

That seems reasonable.  I'd like to add that Lukasz, if he can find
time, will probably be the lead of figuring out gdmsetup.

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

I think it would make sense for you to send an email to gnome-hackers
and desktop-devel-list to let everyone know that you are now a
co-maintainers of GDM and that people should beware that GDM 2.21 is
going to be quite different than what everyone is used to.  The email
probably should contain references to the Wiki to this email discussion
thread.  This way people in the community can be a bit more clear on
what we are proposing to do.

Let's give people a few days to comment and raise concerns.  Assuming
there aren't any serious objections, then please go ahead and make the
changes you propose above to make GDM SVN head contain the new code
for the upcoming 2.21 release.

Sound reasonable?

Brian