I'm attaching an email from Sam Ruby on [EMAIL PROTECTED] that (IMHO) captures how many ASF projects work, and I think begins to lay this framework.
Any and all comments appreciated.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--- Begin Message --- One nice thing about conferences is it permits a number of high bandwidth conversations that aren't practical via e-mail. I've talked to a number of people about the topics that have been discussed on this mailing list, and thought I would share some of my notes. These are merely meant to capture my understanding at this point in time, and not meant to be interpreted as authoritative.
- - -
All ASF projects need to move towards a direction whereby participants with commit privileges, voting rights, and PMC membership are largely converged. The current model whereby an umbrella project is permitted to exist with separate code bases with separate communities and is administered by a PMC which is largely separate from those committers is neither sustainable nor legally defensible. This is not a statement about number of CVS repositories or mailing lists, but merely one of commit privileges and voting rights.
Vetoes are, as a general rule, anti-social behavior and are to be used sparingly. They are to be used to draw attention to stop-ship types of bugs and resolvable design disputes. Simple bugs should simply be handled routinely via e-mail, bug tracking mechanisms, or by directly making the fixes. Significant design disputes should be handled via internal forking � allowing a separate proposal directory or perhaps even CVS tree to be created whereby a speculative design is explored.
Forks should be clearly identified with separate names per the rules for revolutionaries e-mail. For external forks, i.e., ones that reside outside of ASF servers, this is all that is necessary. For internal forks, it is important to realize that the PMC is still accountable for that code and the rules for voting and commit privileges still apply.
In other words, the creation of such internal forks is to be done based on consensus on the scope, visibility, and design direction of such an effort. This does not mean that there needs to be consensus of opinion on the viability of the design approach; merely that the idea merits exploration - even if the ultimate result is only to prove that it is indeed a dead end.
As long this code resides under the purview of an existing PMC, no separate voting or commit rights should be sanctioned for this code. Nor should vetoes be used after the fact to change the agreed upon scope of such an effort.
Separate code bases with separate communities should be separate projects. Independent of the size of the codebase, if the size of the community is only a few people, then it is not an ASF project. Such efforts can be pursued outside of the ASF, be pursued inside the Incubator, or be incorporated inside an existing community � as long as all participants in that larger community are treated as peers.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- End Message ---
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
