Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/801#issuecomment-153863283
John,
I probably shouldn't respond in this thread, but from your response I
feel like much of my point was missed. In fact I had pointed out the very
thing you mention, that there's no requirement for third parties to submit
their code to the community, they could ship their plugin standalone and
have their users install it. If a user has a problem, it won't matter if
the plugin was shipped with CloudStack or installed standalone, the result
will be the same.
I think we are in agreement that the code should have the same
standards, but I think we (and I mean all of us) differ to varying degrees
in what those standards should be. One may block an important commit
because it uses String.length() == 0 instead of String.isEmpty(), or
doesn't print enough debug info, and end up postponing the benefit of the
fixes to the next release, while another committer might not care about
that level of review and standard. There should probably be a basic list of
items to look for so that the reviews themselves can be standardized. I
think that would also address the concern I have for the community culture,
because contributors will fear the review process less if they can see up
front what the criteria are for merge. There's little I can think of that
is more detrimental to growing our community of committers than making
people feel like they're submitted to an arbitrary level of scrutiny
whenever they contribute. When contributing becomes painful then we're held
at arms length, rather than encouraging ownership of the code and
participation.
On Wed, Nov 4, 2015 at 10:35 AM, John Burwell <notificati...@github.com>
wrote:
> I agree with @runseb <https://github.com/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 <https://github.com/KrisSterckx> I realize my comments may
> come across as unappreciative which is not my intention. I greatly
> appreciate the work @nlivens <https://github.com/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 <https://github.com/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 <https://github.com/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 <https://github.com/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.
>
> â
> Reply to this email directly or view it on GitHub
> <https://github.com/apache/cloudstack/pull/801#issuecomment-153822915>.
>
---
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.
---
