Re: The future of the release team



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

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

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.

This doesn't sound too radically different from what we have now (little
steps, little steps). However, it would allow us to choose a release
manager who is free of corporate bias if that was deemed a required
quality (although, I would be sad to not have JDub as release manager).
The TSC would consist of people who were technically brilliant, whoever
employs them. Since their focus wouldn't be on making the desktop better
for redhat, or sun, or canonical, but instead making sure the desktop
was a releasable product, and that 1.3k patch really did need to go in
three days before the gold release.

I do not propose the (assistant) gnome-applets maintainer for any
position involving technical brilliance ;)

--davyd
(Assistant) GNOME Applets Maintainer

-- 
http://davyd.ucc.asn.au/
 
PGP Fingerprint <http://davyd.ucc.asn.au/pgp>
08B0 341A 0B9B 08BB 2118  C060 2EDD BB4F 5191 6CDA

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]