Re: The future of the release team

[Mark McLoughlin <markmc redhat com>]

Hi Davyd,

On Thu, 2004-09-23 at 04:19, Davyd Madeley wrote:
> On Wed, 2004-09-22 at 20:29 +0100, Mark McLoughlin wrote:
> 
> > 	And I agree that you don't want random people taking up these tasks
> > without the ability to do a good job. But its no different from any of
> > the other responsibilities in GNOME - e.g. you don't find incapable
> > people taking up the maintainership of unmaintained modules. Most people
> > are aware of their capabilities and don't generally volunteer for tasks
> > unless they're pretty sure they're not going to embarrass themselves.
> 
> You've forgotten about the (assistant) gnome-applets maintainer then ;)

	No, its a perfect example - gnome-applets regularly becomes
unmaintained and lies pretty much idle until someone comes along with
the time, skills and motivation to take on the job. The important thing
is that its clear who the responsibility for the task lies with, so that
if that person runs out of time and/or motivation its clear someone else
needs to step up.

> > >   5) Reviewing requests to break feature/API/ABI/code freezes
> 
> More seriously, I was going to discuss this last night, but fell asleep.
> 
> 1-4 are easily distributable. I fully support the idea of making these
> more community based. These tasks could easily be controlled by a
> "Release Manager" who arranged with interested volunteers who wanted to
> work on a part (say the release notes) and ensured that it was
> coordinated and sorted out.

	As long as you have motivated people around, someone will step and take
on co-ordinating each task. If you don't have motivated people around
there's nothing the release manager can really do.

	In this case the "Release Manager" would have a single responsibility -
put names against each of the tasks. But the title suggests something
more and might lead people to have the impression that something is
under control, when it isn't. Also, what happens when the release
manager doesn't have time/motivation - the tasks don't get assigned?

	But I don't think we need an assigned person to fill out a little table
of tasks. We should be able to do that amongst ourselves.

> Number 5 is not something that can be handled by a single release
> manager, or a group of volunteers. Instead I would propose a "Technical
> Steering Committee" but the name sounds too much they act as the GNOME
> think-tank (to paraphrase Mark). The goal of this TSC would be to deal
> with goal #5. The TSC would consist of a small number (maybe at most 5)
> contributors selected by the community, who have a broad understanding
> of the codebase and are known to be sane in regards to release critical
> choices. They wouldn't have their own mailing list, instead carry their
> conversation out on d-d-l so that everyone could be involved. But in the
> end, for things like goal #5 it would be their approval you need.

	I think we largely agree, so I'll just say this:

  - Why call it a steering committee? Its a group of people approving 
    freeze break requests. Call a spade a spade and avoid the confusion 
    of responsibilities. They'd be the "Freezing Hard-Asses" (FHA, if
    you prefer).

  - Its still a group of volunteers. If by "selected by the community" 
    you mean they volunteer and if no-one objects they're on, then sure.
    It doesn't require any more bureaucracy than any other volunteering 
    for any task in GNOME, though.

  - I'd like to have the kind of judgement calls we make on freeze 
    breaks codified a lot better, though. Both to make the task easier 
    and so that everyone understands why we have freezes and how we 
    come to our decisions. Call it "Handbook For a Hard-Ass" or 
    whatever.

  - I only suggested a separate mailing list because of the sheer 
    volume of requests and the difficulty in tracking them. Open to 
    everyone, though.

Cheers,
Mark.