New Package Process

[Elliot Lee]

You guys are overthinking this a bit too much.

Practically speaking, anyone can make changes to any package by talking
with and building a relationship with the package maintainer. This is not
rocket science here. You want to get things done, you talk to the right
people - setting up complicated policies is not necessary when having a
designated maintainer is sufficient.

So if you're a maintainer want to set up a maintenance team for a
particular package, that's fine. Just go ahead and do it and don't ask for
permission, affirmation, or whatever. The only rule we really need to 
manage:
	The steering committee or its agents designate the package 
	maintainer.

	The package maintainer sets the rules for working with that 
	package.

On a slightly related note, I'm in favor of what Greg posted about keeping
the initial package review process minimal, and then encouraging an
environment of constant improvement by doing ongoing QA on the packages
that come out of the build system. That will make it easier for people to
learn how to do good packaging, and also focus our package review efforts
on the end results (i.e. QA happens on the built packages) which means
integration issues and end-user issues are more likely to get detected.  
Right now the package review is just finding .spec file style issues
(Summaries that have a period at the end), while being unlikely to detect
things like a package that won't work.

Best,
-- Elliot