Ok, sounds like we'll have a consensus on this. I've added a section to http://wiki.openstack.org/QuantumDevelopment summarizing this. If there are any concerns with the text on the page, let me know.
Dan On Fri, Jun 29, 2012 at 3:32 PM, Kyle Mestery (kmestery) <kmest...@cisco.com > wrote: > On Jun 29, 2012, at 1:50 AM, Dan Wendlandt wrote: > > > Hi folks, > > > > Ryota from NEC sent an email to the list earlier tonight about pushing > their NEC Quantum plugin (currently hosted outside of the main Quantum > repo), into the main Quantum repo. As some of you will recall, at the > Folsom summit we talked a bit about whether plugins should be in core and > if so, what the requirements would be around allowing a plugin to be in the > main repo. > > > > My personal feeling is that having plugins be part of a single > centralized community repository is a good thing for a couple of reasons: > > 1) it simplifies and increases the sharing of code and ideas across > different plugins. > > 2) it promotes a more cohesive community around quantum, encouraging > people to contribute not only to their plugin, but to community projects as > well. > > 3) it potentially makes it easier for someone to understand if a code > change (e.g., at the db plugin base layer) breaks any particular plugin. > > > I agree with all these points, these are the main reasons I think having > plugins in the Quantum repo is the way to go. > > > However, for this approach to work, I think we need to make sure that at > least one core quantum developer is committed to maintaining the plugin. > Why a core member? Because being core represents a significant commitment > to understanding the does and don'ts of Quantum, which that maintainer can > help enforce with respect to the plugin code. A core developer also > presents a commit to the community as a whole, which means other core > developers will be motivated to return the favor and reivew/fix issues > within the plugin. > > > I agree with this, and both Sumit's and Salvatore's comments as well. > Making someone a core dev from their plugin submission means they need to > get involved in other community activities as well. This will also increase > the number of core devs, and it may gate plugins for which authors are not > up to the task or time commitment. They still have the option of > maintaining their plugin outside the Quantum repo. > > Thanks, > Kyle > > > Obviously, we don't want these requirements to be so high that they > discourage people from building and pushing plugin code to the main repo, > because as I mentioned above, I think there are a lot of advantages to > having plugins in a shared location. The core dev might be the primary > developer of the plugin itself, or it might be an existing core developer > who is simply motivated to work with the existing developers to help make > sure the plugin stays in good shape and questions on the ML or launchpad > get answered in a reasonable fashion. > > > > At this point, I would think that all plugins in the repo meet these > criteria, with the exception of the Ryu plugin, as we haven't really had > much contact with those authors since the initial contribution. > > > > What do others think about this topic? What's the right trade-off? > > > > Dan > > > > -- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Dan Wendlandt > > Nicira, Inc: www.nicira.com > > twitter: danwendlandt > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > -- > > Mailing list: https://launchpad.net/~netstack > > Post to : netstack@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~netstack > > More help : https://help.launchpad.net/ListHelp > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
