I also prefer just removing providers which are known or suspected to not work. Unhooking from the build and moving to purgatory are really just delaying the inevitable.
I would like to propose an alternative to blacklisting providers to remove them: create a mapping of provider name to community steward. If we cannot associate a provider with a steward within a few weeks we should just remove the provider. This role should imply some willingness to do code reviews and periodically run integration tests for those providers. We can easily track this on wiki. On Sun, Oct 05, 2014 at 01:12:45PM -0700, Adrian Cole wrote: > Agreed, the attic idea sounds bad for this (and probably most things > in a git world), let's just remove things in a clear way. > > sounds like a job for jira. add a jira to kill the provider, tag that > jira in the commit. Then either via jira or git log, it is clear when > it happened and the single commit that could possibly be reverted. > > > On Sun, Oct 5, 2014 at 1:09 PM, Ignasi Barrera <ignasi.barr...@gmail.com> > wrote: > > Thinking more about this, perhaps it should be better to just remove > > then and note the commit. > > That would prevent users browsing the repo, cloning it (or Google > > indexing it), from trying to build/use providers that don't work. > > > > On 5 October 2014 21:53, Andrew Phillips <aphill...@qrmedia.com> wrote: > >>> Just to complete Adrian's view, I'd add providers that only support > >>> obsolete versions and are unlikely to be updated. > >> > >> > >> In that case, I would definitely prefer to simply remove them and e.g. have > >> a Wiki page listing the providers that are no longer in the repo, together > >> with the commit which removed them. > >> > >> I guess that's not too different from an "attic repo" ;-) I just don't > >> fancy > >> the idea of a jclouds-* repo with code that may not build and almost > >> certainly doesn't work. > >> > >> ap -- Andrew Gaul http://gaul.org/
