I agree, John, that visual code inspection is not sufficient to "prove" the code behaves as expected (too many variables to take into consideration that just examining the code can easily miss problems).
I believe the idea, though, was just to protect the state of the DB since the plug-ins don't run in sandboxes. If a customer wants to use CloudStack with SolidFire and should happen to encounter an issue or question, I would expect the customer would contact SolidFire about the issue/question. I think for some plug-ins that this is the case and for others it is not. I think for the ones where this is not the case (i.e. issues/questions come to the CS community and not to a particular vendor), we should try to enforce more strict community requirements for testing. On Wed, Nov 4, 2015 at 11:35 AM, jburwell <g...@git.apache.org> wrote: > Github user jburwell commented on the pull request: > > https://github.com/apache/cloudstack/pull/801#issuecomment-153822915 > > I agree with @runseb that we need to move this discussion to dev@, > and re-assess accepting the maintenance responsibly for code that cannot be > tested and verified by the community. This plugin has already been > accepted into 4.5, and as such, would be "grandfathered" into any decision > we would make. Therefore, we should carry our current precedent forward > and not prevent acceptance of this PR for this reason. We are at a point > in the 4.6 release cycle that only blockers should be accepted. Otherwise, > we will never ship 4.6. > > @KrisSterckx I realize my comments may come across as unappreciative > which is not my intention. I greatly appreciate the work @nlivens and you > have done to contribute this capability to the community. This plugin > highlights a larger issue which is that, as a community, we are delivering > releases containing code that cannot be verified. By contributing this > plugin to our community, we become responsible for its support and > maintenance. In 6-12 months, how do answer answer a user who asks does > this plugin work in the latest release if you are unavailable? > > @runseb while there is a fairness issue for the contributor, I think > it is incredibly unfair to our users that we ship code without on-going > validation. When a user sees the availability of PluginX supporting > Device1 in a release, they assume that we have verified the proper > operation of PluginX since we shipped it in that release. In fact, we > haven't, and they may be attempting to use something that is completely > broken. > > @mlsorensen yes, plugins provide a mechanism for vendors to extend > CloudStack. However, there is no requirement for those plugins to be part > of the community, OSS codebase. Therefore, we should not conflate the > ability of third-parties to extend CloudStack using plugins with the code > that is accepted as part of the community's repositories. All code in our > repositories, regardless of being in the core or a plugin, should be held > to the same standards. When a user has a problem, they aren't any less > frustrated with the project because their problem happens to be in a plugin. > > @mike-tutkowski I don't believe that code inspection by itself is > adequate to determine the quality of code integrating an external device. > For example, I reviewed the code for this plugin, and while I feel > confident that it will behave well within the management server, I have > absolutely no idea if the various network functions are being properly > automated using the Nuage client APIs. The only way for those aspects of > the plugin's operation to be verified would be to run in a test environment > with a Nuage device and realize a set of network topologies. > > > --- > If your project is set up for it, you can reply to this email and have your > reply appear on GitHub as well. If your project does not have this feature > enabled and wishes so, or if the feature is enabled but not working, please > contact infrastructure at infrastruct...@apache.org or file a JIRA ticket > with INFRA. > --- > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
