On Fri, Jun 29, 2012 at 9:24 AM, Sumit Naiksatam (snaiksat) < snaik...@cisco.com> wrote:
> 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). > Yes, I agree. I think the ideal case is that a plugin developer decides to become a core community member, as this grows the community and the set of people who can work on community projects. I also think the second item you mentioned is important as well: this person should be a true core dev member (review days, team meetings, etc), not just a plugin maintainer that is label of "core". Dan > **** > > ** ** > > 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> 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**** > > 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
