On Mar 14, 2005, at 3:08 AM, Ceki Gülcü wrote:
At 07:53 PM 3/12/2005, Roy T.Fielding wrote:On the contrary, the rule is that you must have at least three binding +1 votes from the PMC in order to make a release of anything.
Roy,
For me, the accepting responsibility over a project, say X, translates into an engagement to take over project X if and when the existing committers stop working on it.
No, that is not what accepting responsibility means. What it means is that the PMC is responsible for ensuring that it is either run as an Apache project (open to new contributors, advancing people to greater responsibility, etc.) or shut down as soon as that proves not to be the case. A one-person project must be encouraged to be a three-plus person project or it simply does not belong at Apache, period. That is a minimum.
When PMC members cast a binding vote on a given release of project X, they are approving the release, in the sense that the release is "OK". Their binding vote does *not* mean that they are able to take over the project in terms of development resources. Thus, accepting responsibility and casting binding votes do not have exactly the same meaning. Would you agree?
No. Binding votes are binding because they have been given responsibility
by the ASF to determine whether it is safe to release the software.
If taking responsibility means exercising oversight over the sub-projects in Logging Services, then I think the LS PMC can only accede to your and Noel's request. That much seems pretty obvious.
However, if taking responsibility means providing the development resources in case a sub-project lacks development resources, we cannot collectively make such a pledge. I also have to say that insisting on such a pledge strikes me as unreasonable. How can a PMC pledge resources it does not have or control? The only development resource the PMC "controls" are the individuals composing the PMC. To be precise, each voting PMC member controls one resource: himself.
Exactly, which is why umbrella projects never work and thus it is better for a project to be forced into growing their own community. Designers are resistant to give up personal control over a project, and the veto allows them to retain enough technical control while still opening up participation. When a subproject only has one or two developers active, we require that the PMC be involved in all release decisions until such time as it successfully encourages additional people to get involved. The only difference between my and Noel's opinion is that I think the logging PMC can take over the community-building role from the incubator PMC once the legal obstacles have been cleared, whereas he seems to believe that the incubator should not graduate a podling until it is ready to be independent.
I would agree with Noel if it weren't for the fact that the incubator PMC does not build communities either -- that role has been entirely left to the mentors, who are typically from the destination PMC. Graduating subprojects earlier would let us focus on the podlings that are destined to be TLPs.
....Roy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
