Platonides wrote: >Even if "labs being ready" happens in 2018? >"ready" will vary for each tool, but I foresee a process like this: > >1. labs provides all the resources needed for $TOOL >2. $AUTHOR signs up in labs, gets added to the projects, etc. >3. $AUTHOR tests (benchmarks) labs and finds it acceptable for $TOOL >4. $AUTHOR learns all the labs-specific details. >5. $AUTHOR allocates some time for installing $TOOL in labs >6. Fix bugs in $TOOL when run in labs (aka. adapt $TOOL to labs) >7. (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 _______________________________________________ Toolserver-l mailing list ([email protected]) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
