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 <notificati...@github.com> 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 infrastruct...@apache.org or file a JIRA ticket with INFRA. ---