I think it's fair to expect that, for a plugin to be in the community repo, it be maintained by at least one core dev. Also, in cases where a new plugin is being introduced by new contributors, at least one of them can be promoted to core dev (if none of the existing core devs take responsibility) on the merit of their contribution to that plugin (and of course with the understanding that they agree to fulfill the core dev responsibilities beyond just that plugin).
Thanks, ~Sumit. From: netstack-bounces+snaiksat=cisco....@lists.launchpad.net [mailto:netstack-bounces+snaiksat=cisco....@lists.launchpad.net] On Behalf Of Salvatore Orlando Sent: Friday, June 29, 2012 12:54 AM To: Dan Wendlandt Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] requirements for quantum plugins Hello Dan & netstack people, replies inline. On 29 June 2012 07:50, Dan Wendlandt <d...@nicira.com<mailto:d...@nicira.com>> 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 on all the above points, however from waht I recall concerns were mainly around i) not well maintained plugins - which you address in this email, and ii) plugins for specific, non widely-available technologies. 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. And, also such core dev will be a subject expert for the technology adopted by that particular plugin. 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. I think one possible idea would be to "promote" one of the commiters for each plugin to core dev. Hopefully this will encourage community engagement. However, we should also probably define some high-level criteria for deciding when a plugin should be removed from the main repo because it's not being maintained, as it might be the case of the Ryu plugin mentioned below. 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<http://www.nicira.com> twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
