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.
---
