Platonides wrote:
Even if "labs being ready" happens in 2018? "ready" will vary for each tool, but I foresee a process like this:
- labs provides all the resources needed for $TOOL
- $AUTHOR signs up in labs, gets added to the projects, etc.
- $AUTHOR tests (benchmarks) labs and finds it acceptable for $TOOL
- $AUTHOR learns all the labs-specific details.
- $AUTHOR allocates some time for installing $TOOL in labs
- Fix bugs in $TOOL when run in labs (aka. adapt $TOOL to labs)
- (Optional) Redirect toolserver/$TOOL to labs/$TOOL
For the majority of tools, we haven't reached #1 yet.
Once labs provides (almost) everything available at toolserver, you can start talking about when to stop supporting TS. But doing otherwise is premature. #2 is the only step that could take place before #1.
Then there is the 'lazy factor' for #2-7, although it is also known as "too busy to fix this program which works ok in TS" Some people may skip #3, while others will want to be damn sure that it will work correctly. The time required by #4 can be reduced making labs very similar to toolserver. If labs environment for the programs is very different, such as needing to do the joins manually inside the program, that will increase #6 a lot.
Platonides: This was an absolutely wonderful e-mail. Thank you for putting it together. :-)
In some ways, as others have noted, convincing people to switch to Labs earlier would slowly reduce the Toolserver's load. Or instead of convincing, forcing users who are currently using a disproportionately high amount of resources for their tools.
But... I imagine most resource-intensive tools need database replication up and running. Maybe by the end of this month? Fingers crossed.
MZMcBride