Aaron Bannert wrote:
On Fri, Oct 25, 2002 at 12:32:17AM -0700, Justin Erenkrantz wrote:
The PMCs job should be to stay the heck out of the way of the committers.
I agree with this, once the PMC has defined a clear mission.
The more you clarify scope and stucture - the more accountability you assign to yourselves. With clear accountability the community can be more responsible - with demonstrated responsibility the PMC should in principal stay out of the way of the committers (at least if the PMC follwoing the model of the Jakarta process).
If the committers need help, they can ask the PMC for guidance, but let's not have a PMC that dictates from upon high.
Dictate is a strong word. I haven't experienced any ASF PMC which
has dictated from upon high. What kinds of things are you worried
about, specifically?
PMC's have some things to dictate - license policy - voting policy - security policy - duspute resolution mechanisms. The PMC could choose to use the Jakata policies with would be a good starting point.
Note that as a committer I have very rigid requirements for what a release is, what coding style, and what build system to use. But, I don't believe the PMC should dictate to *me* what tools I use.
Agreed.
But you may want to look further into the implications of "release". The PMC is accountable to the board. The board shoud be imformed about a release (it increases Apache legal exposure). This means that the PMC should be notifying the board of impending releases. The community here should be driving the PMC - make sure you have a process in place that makes those guys on the PMC work for you!!!
Cheers, Steve.
(One reason I'm against using Ant commons-wide - it sucks for C code which is about all I care about.) -- justin
+1 :)
-aaron
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell
OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net
