<html><body>
<p><tt>project-planning-bounces@ovirt.org wrote on 09/09/2011 03:08:17 PM:<br>
&gt; &gt; One concern I have is that this seems to enforce that all projects are<br>
&gt; &gt; managed via consensus. &nbsp;But many existing (and successful) Open Source<br>
&gt; &gt; projects don't use an Apache-style consensus model but rather rely on<br>
&gt; &gt; a benevolent dictatorship or some variation thereof.<br>
&gt; &gt;<br>
&gt; &gt; I think it's fine to use a consensus model for oVirt business, but I<br>
&gt; &gt; think it's important to allow sub projects to use other types of<br>
&gt; &gt; leadership models. &nbsp;Otherwise you're excluding large parts of the<br>
&gt; &gt; existing community, most notably, libvirt, QEMU, and KVM.<br>
&gt; &gt;<br>
&gt; &gt; So I think for project specific things (like whether a project is<br>
&gt; &gt; ready for a release) needs to be completely deferred to the sub project.<br>
&gt; &gt;<br>
&gt; &gt; If the sub project needs to somehow codify how it makes decisions,<br>
&gt; &gt; that's fine, but the sub project should ultimately have the say over<br>
&gt; &gt; how it makes decisions. <br>
&gt; <br>
&gt; <br>
&gt; The goal is for each sub-project to get to 3 or more maintainers, which<br>
&gt; rules out the benevolent dictatorship model for sub-projects. The goal<br>
&gt; here is to build a growing and sustainable community not reliant on<br>
&gt; single individuals.<br>
&gt; <br>
&gt; Think of it as at least three benevolent dictators per sub-project, or<br>
&gt; if the project has less than three, the board helps provide<br>
&gt; accountability. For projects like KVM, QEMU, libvirt, if they joined in<br>
&gt; we would encourage them vote on additional maintainers. It is hard to<br>
&gt; argue any downside to doing that.<br>
</tt><br>
<tt>I agree that we need to encourage and require more than one maintainer per project and I like the rule. I don't think we want to force a change in existing projects that are successful like KVM &amp; QEMU. In both of these cases we have projects with a long history of broad contributions. Or we should recognize that kVM and QEMU have de-facto sub-mainterships due to the practice of regular almost automatic pulling of source trees published by key contributors.</tt><br>
<br>
<tt>Thanks,</tt><br>
<br>
<tt>Mike</tt><br>
<br>
<tt>Mike Day</tt><br>
<tt>IBM Distinguished Engineer</tt><br>
<tt>Chief Virtualization Architect, Open Systems Development</tt><br>
<tt>Cell: +1 919 371-8786 | mdday@us.ibm.com</tt><br>
<tt><a href="http://code.ncultra.org">http://code.ncultra.org</a> </tt></body></html>