+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 <adrian.f.c...@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
