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 > >
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
