On 29 June 2012 09:51, Dan Wendlandt <d...@nicira.com> wrote: > > > 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". >
True. This is exactly what I meant when I said that this "promotion" - which is not really an award, given the amount of work a core is supposed to do :) - would enhance community engagement. As for the Ryu plugin, I did not meant to say that it is not well maintained, but just remark that maintainers for that plugin are not integrated in the community in the same way as the maintainers for the other plugins are. I apologise If I gave the impression I stated the Ryu plugin is not well maintained. > 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
