unhook unmaintained providers from master

[Adrian Cole <ad...@gmail.com>]

Hi, team.

I have noticed that there's a lot of maintenance still going on for
providers that are not only in labs, but haven't had any feature work
in over a year. Some of these are in fact dead and could be removed.
Others are far behind in versions. In any case, providers with no
owner or live tests run are simply tech debt.

Here's a suggestion for a start.

unhook aging code such as the jenkins, virtualbox, savvis, etc
providers from master.
keep them in 1.8.x branch, and keep that compiling, but don't release
them in 2.x

Later, we can suggest a process for a real attic -> /dev/null for
things that are "not quite dead, yet"

The thing is, that if there's a provider that hasn't been touched in
over a year, it needs a significant helping of work to refactor into
current approach, and nothing in labs should exit as an antique
anyway. Meanwhile this frees us up to modernize core, such as removing
async, etc.

At the end of the day, we need to be able to both start and complete
hard things. Labs providers, especially orphaned ones, shouldn't get
in the way of the latter.

Thoughts?
-A

Re: unhook unmaintained providers from master

[Andrew Phillips <ap...@qrmedia.com>]

> create a mapping of provider name to community steward

That's what I was also trying to describe with the suggestion:

> b) if we want to, call out to user@ and/or the provider to see if  
> there's any interest in adopting

Certainly think it's a good idea to try!

ap

Re: unhook unmaintained providers from master

[Andrew Gaul <ga...@apache.org>]

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 <ig...@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 <ap...@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/

Re: unhook unmaintained providers from master

[Adrian Cole <ad...@gmail.com>]

:) I'd love that problem!

On Sun, Oct 5, 2014 at 3:19 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
>> Is this necessary? I think we are cart before horse, debating SEO
>> friendliness of how to find a commit id.
>
>
> Agreed that we don't need to worry about this now. We can always think about
> what to do if suddenly there's indeed a miraculous rush of contributors
> looking to work on old providers.
>
> ap

Re: unhook unmaintained providers from master

[Andrew Phillips <ap...@qrmedia.com>]

> Is this necessary? I think we are cart before horse, debating SEO
> friendliness of how to find a commit id.

Agreed that we don't need to worry about this now. We can always think  
about what to do if suddenly there's indeed a miraculous rush of  
contributors looking to work on old providers.

ap

Re: unhook unmaintained providers from master

[Adrian Cole <ad...@gmail.com>]

Is this necessary? I think we are cart before horse, debating SEO
friendliness of how to find a commit id. It is a rare case that anyone
helps on old providers anyway (who would be looking for that commit).
If they can't find it from git log or jiras, I'm sure someone else on
the dev team could, right?

-A

On Sun, Oct 5, 2014 at 1:26 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
>> 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.
>
>
> +1 for using JIRA to record the details. I don't know how well searchable
> JIRA is, though - it would be nice if someone searching for "jclouds
> <attic-provider-name>" in a search engine would be able to find a link to
> that commit...
>
> ap

Re: unhook unmaintained providers from master

[Andrew Phillips <ap...@qrmedia.com>]

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

+1 for using JIRA to record the details. I don't know how well  
searchable JIRA is, though - it would be nice if someone searching for  
"jclouds <attic-provider-name>" in a search engine would be able to  
find a link to that commit...

ap

Re: unhook unmaintained providers from master

[Adrian Cole <ad...@gmail.com>]

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 <ig...@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 <ap...@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

Re: unhook unmaintained providers from master

[Ignasi Barrera <ig...@gmail.com>]

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

Re: unhook unmaintained providers from master

[Andrew Phillips <ap...@qrmedia.com>]

> 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

Re: unhook unmaintained providers from master

[Ignasi Barrera <ig...@gmail.com>]

Just to complete Adrian's view, I'd add providers that only support
obsolete versions and are unlikely to be updated.

On 5 October 2014 21:22, Adrian Cole <ad...@gmail.com> wrote:
> Something that is dead imho is code that refers to a provider that
> no-longer exists or operates, or has been in labs, but not progressed
> for a year.
>
> Something not-quite-dead would be a provider that might still work,
> but hasn't had live tests or notable work in a year, so we don't
> really know.
>
> I'm sure we could clarify these terms :)
>
> -A
>
>
> On Sun, Oct 5, 2014 at 11:49 AM, Andrew Phillips <ap...@qrmedia.com> wrote:
>>> Later, we can suggest a process for a real attic -> /dev/null for
>>> things that are "not quite dead, yet"
>>
>>
>> What's the definition of "not quite dead, yet"? ;-) "They can still be
>> used", or "there is potential for modernization", or other? If something
>> really cannot be used, my suggestion would be to
>>
>> a) unhook from the release process for now, so we are not blocked
>> b) if we want to, call out to user@ and/or the provider to see if there's
>> any interest in adopting
>> c) remove from the repo, storing the commit ID somewhere in a Wiki so we can
>> "retrieve" the code if needed.
>>
>> I'm not sure what the advantage is of an "attic" that is different from out
>> GitHub repo?
>>
>> ap

Re: unhook unmaintained providers from master

[Adrian Cole <ad...@gmail.com>]

Something that is dead imho is code that refers to a provider that
no-longer exists or operates, or has been in labs, but not progressed
for a year.

Something not-quite-dead would be a provider that might still work,
but hasn't had live tests or notable work in a year, so we don't
really know.

I'm sure we could clarify these terms :)

-A


On Sun, Oct 5, 2014 at 11:49 AM, Andrew Phillips <ap...@qrmedia.com> wrote:
>> Later, we can suggest a process for a real attic -> /dev/null for
>> things that are "not quite dead, yet"
>
>
> What's the definition of "not quite dead, yet"? ;-) "They can still be
> used", or "there is potential for modernization", or other? If something
> really cannot be used, my suggestion would be to
>
> a) unhook from the release process for now, so we are not blocked
> b) if we want to, call out to user@ and/or the provider to see if there's
> any interest in adopting
> c) remove from the repo, storing the commit ID somewhere in a Wiki so we can
> "retrieve" the code if needed.
>
> I'm not sure what the advantage is of an "attic" that is different from out
> GitHub repo?
>
> ap

Re: unhook unmaintained providers from master

[Andrew Phillips <ap...@qrmedia.com>]

> Later, we can suggest a process for a real attic -> /dev/null for
> things that are "not quite dead, yet"

What's the definition of "not quite dead, yet"? ;-) "They can still be  
used", or "there is potential for modernization", or other? If  
something really cannot be used, my suggestion would be to

a) unhook from the release process for now, so we are not blocked
b) if we want to, call out to user@ and/or the provider to see if  
there's any interest in adopting
c) remove from the repo, storing the commit ID somewhere in a Wiki so  
we can "retrieve" the code if needed.

I'm not sure what the advantage is of an "attic" that is different  
from out GitHub repo?

ap

Re: unhook unmaintained providers from master

[Andrew Phillips <ap...@qrmedia.com>]

PS: Many thanks, Adrian, for taking on so much of this work!

ap

Re: unhook unmaintained providers from master

[Adrian Cole <ad...@gmail.com>]

https://issues.apache.org/jira/browse/JCLOUDS-745

On Sun, Oct 5, 2014 at 8:13 AM, Ignasi Barrera <ig...@gmail.com> wrote:
> +1
>
> On 5 October 2014 17:10, Adrian Cole <ad...@gmail.com> wrote:
>> Cool. In the meantime, things that have been unhooked and not released
>> since 1.5 should all be removed (there are still a few like this in
>> jclouds-labs). Sound good?
>>
>> -A
>> On Oct 5, 2014 7:58 AM, "Ignasi Barrera" <na...@apache.org> wrote:
>>
>>> +1 to the creation of an Attic.
>>>
>>> We have many providers that haven't had any contribution for a long
>>> time and many we can't test because we don't have credentials. That
>>> makes maintaining them extremely difficult and releasing them provides
>>> very little value, specially those we already know that are broken.
>>>
>>> I think the plan to detach those providers from the release process as
>>> a first step and then creating an attic is a good way to proceed. It
>>> would be good to come up with the list of the "dead" providers (or
>>> attic candidates) here in the dev@ list first, so everyone is aware of
>>> what's going to be moved and can discuss
>>>
>>> I..
>>>
>>> On 2 October 2014 20:25, Adrian Cole <ad...@gmail.com> wrote:
>>> > Hi, team.
>>> >
>>> > I have noticed that there's a lot of maintenance still going on for
>>> > providers that are not only in labs, but haven't had any feature work
>>> > in over a year. Some of these are in fact dead and could be removed.
>>> > Others are far behind in versions. In any case, providers with no
>>> > owner or live tests run are simply tech debt.
>>> >
>>> > Here's a suggestion for a start.
>>> >
>>> > unhook aging code such as the jenkins, virtualbox, savvis, etc
>>> > providers from master.
>>> > keep them in 1.8.x branch, and keep that compiling, but don't release
>>> > them in 2.x
>>> >
>>> > Later, we can suggest a process for a real attic -> /dev/null for
>>> > things that are "not quite dead, yet"
>>> >
>>> > The thing is, that if there's a provider that hasn't been touched in
>>> > over a year, it needs a significant helping of work to refactor into
>>> > current approach, and nothing in labs should exit as an antique
>>> > anyway. Meanwhile this frees us up to modernize core, such as removing
>>> > async, etc.
>>> >
>>> > At the end of the day, we need to be able to both start and complete
>>> > hard things. Labs providers, especially orphaned ones, shouldn't get
>>> > in the way of the latter.
>>> >
>>> > Thoughts?
>>> > -A
>>>

Re: unhook unmaintained providers from master

[Ignasi Barrera <ig...@gmail.com>]

+1

On 5 October 2014 17:10, Adrian Cole <ad...@gmail.com> wrote:
> Cool. In the meantime, things that have been unhooked and not released
> since 1.5 should all be removed (there are still a few like this in
> jclouds-labs). Sound good?
>
> -A
> On Oct 5, 2014 7:58 AM, "Ignasi Barrera" <na...@apache.org> wrote:
>
>> +1 to the creation of an Attic.
>>
>> We have many providers that haven't had any contribution for a long
>> time and many we can't test because we don't have credentials. That
>> makes maintaining them extremely difficult and releasing them provides
>> very little value, specially those we already know that are broken.
>>
>> I think the plan to detach those providers from the release process as
>> a first step and then creating an attic is a good way to proceed. It
>> would be good to come up with the list of the "dead" providers (or
>> attic candidates) here in the dev@ list first, so everyone is aware of
>> what's going to be moved and can discuss
>>
>> I..
>>
>> On 2 October 2014 20:25, Adrian Cole <ad...@gmail.com> wrote:
>> > Hi, team.
>> >
>> > I have noticed that there's a lot of maintenance still going on for
>> > providers that are not only in labs, but haven't had any feature work
>> > in over a year. Some of these are in fact dead and could be removed.
>> > Others are far behind in versions. In any case, providers with no
>> > owner or live tests run are simply tech debt.
>> >
>> > Here's a suggestion for a start.
>> >
>> > unhook aging code such as the jenkins, virtualbox, savvis, etc
>> > providers from master.
>> > keep them in 1.8.x branch, and keep that compiling, but don't release
>> > them in 2.x
>> >
>> > Later, we can suggest a process for a real attic -> /dev/null for
>> > things that are "not quite dead, yet"
>> >
>> > The thing is, that if there's a provider that hasn't been touched in
>> > over a year, it needs a significant helping of work to refactor into
>> > current approach, and nothing in labs should exit as an antique
>> > anyway. Meanwhile this frees us up to modernize core, such as removing
>> > async, etc.
>> >
>> > At the end of the day, we need to be able to both start and complete
>> > hard things. Labs providers, especially orphaned ones, shouldn't get
>> > in the way of the latter.
>> >
>> > Thoughts?
>> > -A
>>

Re: unhook unmaintained providers from master

[Adrian Cole <ad...@gmail.com>]

Cool. In the meantime, things that have been unhooked and not released
since 1.5 should all be removed (there are still a few like this in
jclouds-labs). Sound good?

-A
On Oct 5, 2014 7:58 AM, "Ignasi Barrera" <na...@apache.org> wrote:

> +1 to the creation of an Attic.
>
> We have many providers that haven't had any contribution for a long
> time and many we can't test because we don't have credentials. That
> makes maintaining them extremely difficult and releasing them provides
> very little value, specially those we already know that are broken.
>
> I think the plan to detach those providers from the release process as
> a first step and then creating an attic is a good way to proceed. It
> would be good to come up with the list of the "dead" providers (or
> attic candidates) here in the dev@ list first, so everyone is aware of
> what's going to be moved and can discuss
>
> I..
>
> On 2 October 2014 20:25, Adrian Cole <ad...@gmail.com> wrote:
> > Hi, team.
> >
> > I have noticed that there's a lot of maintenance still going on for
> > providers that are not only in labs, but haven't had any feature work
> > in over a year. Some of these are in fact dead and could be removed.
> > Others are far behind in versions. In any case, providers with no
> > owner or live tests run are simply tech debt.
> >
> > Here's a suggestion for a start.
> >
> > unhook aging code such as the jenkins, virtualbox, savvis, etc
> > providers from master.
> > keep them in 1.8.x branch, and keep that compiling, but don't release
> > them in 2.x
> >
> > Later, we can suggest a process for a real attic -> /dev/null for
> > things that are "not quite dead, yet"
> >
> > The thing is, that if there's a provider that hasn't been touched in
> > over a year, it needs a significant helping of work to refactor into
> > current approach, and nothing in labs should exit as an antique
> > anyway. Meanwhile this frees us up to modernize core, such as removing
> > async, etc.
> >
> > At the end of the day, we need to be able to both start and complete
> > hard things. Labs providers, especially orphaned ones, shouldn't get
> > in the way of the latter.
> >
> > Thoughts?
> > -A
>

Re: unhook unmaintained providers from master

[Ignasi Barrera <na...@apache.org>]

+1 to the creation of an Attic.

We have many providers that haven't had any contribution for a long
time and many we can't test because we don't have credentials. That
makes maintaining them extremely difficult and releasing them provides
very little value, specially those we already know that are broken.

I think the plan to detach those providers from the release process as
a first step and then creating an attic is a good way to proceed. It
would be good to come up with the list of the "dead" providers (or
attic candidates) here in the dev@ list first, so everyone is aware of
what's going to be moved and can discuss

I..

On 2 October 2014 20:25, Adrian Cole <ad...@gmail.com> wrote:
> Hi, team.
>
> I have noticed that there's a lot of maintenance still going on for
> providers that are not only in labs, but haven't had any feature work
> in over a year. Some of these are in fact dead and could be removed.
> Others are far behind in versions. In any case, providers with no
> owner or live tests run are simply tech debt.
>
> Here's a suggestion for a start.
>
> unhook aging code such as the jenkins, virtualbox, savvis, etc
> providers from master.
> keep them in 1.8.x branch, and keep that compiling, but don't release
> them in 2.x
>
> Later, we can suggest a process for a real attic -> /dev/null for
> things that are "not quite dead, yet"
>
> The thing is, that if there's a provider that hasn't been touched in
> over a year, it needs a significant helping of work to refactor into
> current approach, and nothing in labs should exit as an antique
> anyway. Meanwhile this frees us up to modernize core, such as removing
> async, etc.
>
> At the end of the day, we need to be able to both start and complete
> hard things. Labs providers, especially orphaned ones, shouldn't get
> in the way of the latter.
>
> Thoughts?
> -A