Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/801#issuecomment-153499188
I largely agree, it provides the best experience for our end users if
we can always verify that plugins are functional and maintainable. On the
flip side, it seems that's part of the point of plugins. It isolates vendor
or implementation-specific code, making it easier to pick up by someone
else who may have domain knowledge but not CloudStack knowledge, or to easy
to remove if it becomes dead code.
In the case of vendors, if they stop their involvement, the most likely
end result is that the code won't be maintained, and if we haven't been
given means to test then we won't know on our own if it is functional. If
the vendor has ended involvement though, even if they've provided means to
test the code then those means may become defunct as well (e.g. software,
system, or license is deprecated), so providing means to the community for
testing doesn't seem to help much if we don't have continued vendor
support. In the past we have simply held a community vote to determine who
cares about the plugin, followed by removal, or if there's someone who
cares about the code and is in a position to maintain and provide testing
for it, they become the community maintainer for that code.
One note of caution, the nature of the plugin architecture also
provides room for vendors to work on their own and provide their code
and/or artifacts to their customers. Short of the tiny core changes in this
request, they don't need to provide this code to the community. I'd prefer
to err on the side of being inviting to vendor contributions and bring the
developers into the community, rather than holding them at arm's length and
asking for a clean handoff or insurance policy in case they disappear.
We've seen community members jump jobs and still stick around because they
found an inviting environment where their contributions were welcomed and
valued, and they grew within the community, and I almost consider that
culture more important than ensuring any maintainer's duties can be
replaced by someone else in the community.
Then again, I'm only tangentially involved in the community right now,
so I won't feel bad if anyone takes my opinion with a grain of salt.
TL; DR - While I'd really, really like to see vendors provide support
to make their plugins testable by the community, I don't think that it buys
us much in regards to maintaining the plugin if the vendor stops their
community involvement, short of having donated hardware with perpetual
license and free updates. As such, I'd rather lower the bar for developers
to maintain their plugin code, with the fallback of being able to easily
remove abandoned plugin code as a last resort.
On Tue, Nov 3, 2015 at 12:11 PM, John Burwell <[email protected]>
wrote:
> @ustcweizhou <https://github.com/ustcweizhou> @remibergsma
> <https://github.com/remibergsma> this is a massive technical debt that we
> are carrying with other plugins, and I think we need to stop to expanding
> that debt. In some cases, we (i.e. ASF) have been granted licenses for
> virtual appliances to test plugin operation (a completely valid way to
> verify operation). For others, we are shipping code that has not been
> verified for a number of releases. In the past, plugins have been
> contributed and tested for a release, but those contributors have not
> remained active to maintain the plugin. Since the community lacks the
> equipment or test rigs, no one else can pick up maintenance -- leaving us
> with bit rotting code. In summary, as a community, we should not be
> accepting the responsibility to support and maintain code whose operation
> we cannot verify -- plugin or core. The question of what to do with
> existing plugi ns that don't meet this criteria is a discussion for
another
> thread.
>
> â
> Reply to this email directly or view it on GitHub
> <https://github.com/apache/cloudstack/pull/801#issuecomment-153473377>.
>
---
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 [email protected] or file a JIRA ticket
with INFRA.
---
