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.
The one thing I can be absolutely sure of is that this PMC will not be involved in disputes about code *ever*. (No, I don't speak for the entire PMC.) There will be no 'veto override' and 'veto of last resort' or any other such nonsense. If dueling vetos exist, I couldn't care less what the PMC says - it's the job of the committers (and the relevant community) to duke it out.
Whenever two committers get in a fight, they shouldn't be running to 'Mommy PMC' to solve their problems. Namely because both of them will probably be on the PMC anyway. So, it's not going to be that productive.
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!!!
No, I don't think the board needs to be notified when a release occurs. The PMC should be large enough that whomever does the release is on the PMC. That's good enough for me.
I would imagine that the PMC would take a reactive role in the event of problems with a release. (Mainly due to inappropriate licensing.) If the code is of poor quality, that, IMHO, really isn't the problem of the PMC. Well, it might cause the PMC to look at the community and considering folding it, but that's about it. -- justin
