Re: [Toolserver-l] Toolserver limitation to come?

[Patricia Pintilie]

Remove wiki offline
Do not allow diffrent languages on same feeds
Delete unused accounts
Delete dangerous information
Acknowledge that the sole creator could be anyone, and expects more order
in a hectic database with too much junk being reedited over and over.
Once its written correctly do not allow repeaters to do over incorrectly
work that was ligit.
Figure out how many angles are approaching the database.
This toolserver can cause havoc or can contain order depends on proper
knowledge used in operating it.
Thanks
MILASTAR.TS.RO
On May 1, 2013 9:17 PM, "Patricia Pintilie" 
wrote:

> http://creativecommons.org/licenses/by/3.0/";> alt="Creative Commons License" style="border-width:0" src="
> http://i.creativecommons.org/l/by/3.0/88x31.png"; />This work is
> licensed under a http://creativecommons.org/licenses/by/3.0/";>Creative Commons Attribution
> 3.0 Unported License.
> On May 1, 2013 8:49 PM, "Ryan Lane"  wrote:
>
>> On Wed, May 1, 2013 at 5:03 PM, Tim Landscheidt 
>> wrote:
>>
>>> Hi,
>>>
>>> at the office hour yesterday
>>> (cf.
>>> http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20130430.txt):
>>>
>>> | [...]
>>> |  multichill: The long story short; replicating
>>> | databases is happening soon (Within the month)
>>> | Replicating multiple copies of commons and wikidata
>>> | isn't going to happen that way; it needs to be built
>>> | into application logic or using federated tables.
>>> | Almost /all/ of the problems the TS have had with
>>> | replication were caused by that redundancy and
>>> | trying to keep it synced.
>>> |  Coren: So you're basically saying Toollabs is
>>> |  useless for me
>>> |  {{ref needed}}
>>> |  We're all more than happy to help you (and any other
>>> | maintainer) with adapting your tools to work in that
>>> | setup.
>>> |  Coren: In that case, Tools will not be able to
>>> |   replace Toolserver.
>>> |  what are federated tables btw?
>>> |  AFAIK toolserver will also have this limitation
>>> | at some point
>>> |  Ryan_Lane: What do you mean?
>>> | [...]
>>>
>>> There were never answers to this, so I bring it up here
>>> again:
>>>
>>> 1. How were "almost /all/ of the problems the TS have had
>>>with replication" "caused by that redundancy and trying
>>>to keep it synced"?
>>>
>>> 2. What limitation will the Toolserver have at some point?
>>>
>>>
>> As to #2: From what I've been told this has to do with future sharding
>> plans for the databases, and due to a change in how we'll be doing
>> replication. Of course, I've heard this in passing. For answers to both of
>> these questions you'll need to talk to binasher and/or notpeter on IRC, as
>> they are the ones doing the database work.
>>
>> - Ryan
>>
>> ___
>> Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
>> https://lists.wikimedia.org/mailman/listinfo/toolserver-l
>> Posting guidelines for this list:
>> https://wiki.toolserver.org/view/Mailing_list_etiquette
>>
>
___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Toolserver limitation to come?

[Patricia Pintilie]

http://creativecommons.org/licenses/by/3.0/";>http://i.creativecommons.org/l/by/3.0/88x31.png"; />This work is
licensed under a http://creativecommons.org/licenses/by/3.0/";>Creative Commons Attribution
3.0 Unported License.
On May 1, 2013 8:49 PM, "Ryan Lane"  wrote:

> On Wed, May 1, 2013 at 5:03 PM, Tim Landscheidt 
> wrote:
>
>> Hi,
>>
>> at the office hour yesterday
>> (cf.
>> http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20130430.txt):
>>
>> | [...]
>> |  multichill: The long story short; replicating
>> | databases is happening soon (Within the month)
>> | Replicating multiple copies of commons and wikidata
>> | isn't going to happen that way; it needs to be built
>> | into application logic or using federated tables.
>> | Almost /all/ of the problems the TS have had with
>> | replication were caused by that redundancy and
>> | trying to keep it synced.
>> |  Coren: So you're basically saying Toollabs is
>> |  useless for me
>> |  {{ref needed}}
>> |  We're all more than happy to help you (and any other
>> | maintainer) with adapting your tools to work in that
>> | setup.
>> |  Coren: In that case, Tools will not be able to
>> |   replace Toolserver.
>> |  what are federated tables btw?
>> |  AFAIK toolserver will also have this limitation
>> | at some point
>> |  Ryan_Lane: What do you mean?
>> | [...]
>>
>> There were never answers to this, so I bring it up here
>> again:
>>
>> 1. How were "almost /all/ of the problems the TS have had
>>with replication" "caused by that redundancy and trying
>>to keep it synced"?
>>
>> 2. What limitation will the Toolserver have at some point?
>>
>>
> As to #2: From what I've been told this has to do with future sharding
> plans for the databases, and due to a change in how we'll be doing
> replication. Of course, I've heard this in passing. For answers to both of
> these questions you'll need to talk to binasher and/or notpeter on IRC, as
> they are the ones doing the database work.
>
> - Ryan
>
> ___
> Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
> https://lists.wikimedia.org/mailman/listinfo/toolserver-l
> Posting guidelines for this list:
> https://wiki.toolserver.org/view/Mailing_list_etiquette
>
___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Survey: Moving to Labs

[MZMcBride]

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 (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Toolserver limitation to come?

[Ryan Lane]

On Wed, May 1, 2013 at 5:03 PM, Tim Landscheidt wrote:

> Hi,
>
> at the office hour yesterday
> (cf. http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20130430.txt
> ):
>
> | [...]
> |  multichill: The long story short; replicating
> | databases is happening soon (Within the month)
> | Replicating multiple copies of commons and wikidata
> | isn't going to happen that way; it needs to be built
> | into application logic or using federated tables.
> | Almost /all/ of the problems the TS have had with
> | replication were caused by that redundancy and
> | trying to keep it synced.
> |  Coren: So you're basically saying Toollabs is
> |  useless for me
> |  {{ref needed}}
> |  We're all more than happy to help you (and any other
> | maintainer) with adapting your tools to work in that
> | setup.
> |  Coren: In that case, Tools will not be able to
> |   replace Toolserver.
> |  what are federated tables btw?
> |  AFAIK toolserver will also have this limitation
> | at some point
> |  Ryan_Lane: What do you mean?
> | [...]
>
> There were never answers to this, so I bring it up here
> again:
>
> 1. How were "almost /all/ of the problems the TS have had
>with replication" "caused by that redundancy and trying
>to keep it synced"?
>
> 2. What limitation will the Toolserver have at some point?
>
>
As to #2: From what I've been told this has to do with future sharding
plans for the databases, and due to a change in how we'll be doing
replication. Of course, I've heard this in passing. For answers to both of
these questions you'll need to talk to binasher and/or notpeter on IRC, as
they are the ones doing the database work.

- Ryan
___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

[Toolserver-l] Toolserver limitation to come?

[Tim Landscheidt]

Hi,

at the office hour yesterday
(cf. http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20130430.txt):

| [...]
|  multichill: The long story short; replicating
| databases is happening soon (Within the month)
| Replicating multiple copies of commons and wikidata
| isn't going to happen that way; it needs to be built
| into application logic or using federated tables.
| Almost /all/ of the problems the TS have had with
| replication were caused by that redundancy and
| trying to keep it synced.
|  Coren: So you're basically saying Toollabs is
|  useless for me
|  {{ref needed}}
|  We're all more than happy to help you (and any other
| maintainer) with adapting your tools to work in that
| setup.
|  Coren: In that case, Tools will not be able to
|   replace Toolserver.
|  what are federated tables btw?
|  AFAIK toolserver will also have this limitation
| at some point
|  Ryan_Lane: What do you mean?
| [...]

There were never answers to this, so I bring it up here
again:

1. How were "almost /all/ of the problems the TS have had
   with replication" "caused by that redundancy and trying
   to keep it synced"?

2. What limitation will the Toolserver have at some point?

Tim


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] enwiki_p corruption

[Hazard-SJ]

Yes, I checked and the correct value was returned:

mysql> select count(*) from imagelinks where il_to = 'Flag_of_Seattle.svg';
+--+
| count(*) |
+--+
|    2 |
+--+
1 row in set (0.01 sec)


 
Hazard-SJ




 From: DaB. 
To: Wikimedia Toolserver  
Sent: Monday, April 29, 2013 2:42 PM
Subject: Re: [Toolserver-l] enwiki_p corruption
 

Hello,
At Monday 29 April 2013 21:32:43 DaB. wrote:
> enwiki_p needs dumped and re-imported.

yes and no. We have 2 servers for enwiki and only 1 of it is re-setuped yet 
(this one returns the correct value – I checked). There are 3 problems: 
* 1 server can not carry the load so during the downtime our enwp-replag would 
increase.
* The replag of wikidata and commons on the "good" server is very high and 
does not really decrease at the moment
* The discs of the "good" server are (most likely) too small to store enwp, 
commons, wikidata and the user-databases – so no user-databases would be 
available during the re-setup.

Another problem was that I had less time in the last weeks than before because 
my university started again. We will find a solution for all problems but it 
will take a while. So if you need accurate data for enwp, please query sql-s1-
rr (you should always do this BTW).

Sincerely,
DaB.


-- 
Userpage: [[:w:de:User:DaB.]] — PGP: 0x2d3ee2d42b255885
___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Survey: Moving to Labs

[Platonides]

On 01/05/13 21:53, DaB. wrote:
> Hello all,
> 
> until now I had the impression that we (you, the authors, and me) fight 
> together against WMF and WMDE for keeping the Toolserver and against Labs. 
> Some mails and discussion in the last days gives me now the impression that 
> this was wrong and (at least some of) you are eager to leave the toolserver 
> as 
> soon as possible.

It does look at times as if they wanted to remove the toolserver from
behind us, but it shouldn't be considered a fight.
In this situation, the interest for that new-über-replacement it's
completely normal. It doesn't mean that they love one more than the other.


> There is no point to beg the WMDE for new hardware and to invest much more 
> time if 2 weeks after Labs is "ready" the toolserver will be empty. For this 
> reason I created a survey at [1] that starts at midnight. Please take a 
> moment 
> of your time and place your nick in the section that suits you.
> 
> Sincerely,
> DaB.

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.


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Survey: Moving to Labs

[Ryan Lane]

On Wed, May 1, 2013 at 12:53 PM, DaB.  wrote:

> Hello all,
>
> until now I had the impression that we (you, the authors, and me) fight
> together against WMF and WMDE for keeping the Toolserver and against Labs.
> Some mails and discussion in the last days gives me now the impression that
> this was wrong and (at least some of) you are eager to leave the
> toolserver as
> soon as possible.
> There is no point to beg the WMDE for new hardware and to invest much more
> time if 2 weeks after Labs is "ready" the toolserver will be empty. For
> this
> reason I created a survey at [1] that starts at midnight. Please take a
> moment
> of your time and place your nick in the section that suits you.
>
>
I'm confused. I thought we were all here to support the readers, editors,
researchers and developers of the Wikimedia projects? If the toolserver is
empty because Labs is accomplishing the goal, isn't that a good thing?

I've asked this before: why not help with Labs, rather than fighting
everyone? Let's work as a team and have a well supported, well funded
product that's run by all of us, with a larger scope that incorporates
infrastructure and development volunteers. We appreciate your work on the
Toolserver and would appreciate it in Labs as well.

- Ryan
___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Survey: Moving to Labs

[Liangent]

On Thu, May 2, 2013 at 4:05 AM, Tim Landscheidt  wrote:
> (anonymous) wrote:
>
>>> until now I had the impression that we (you, the authors, and me) fight
>>> together against WMF and WMDE for keeping the Toolserver and against Labs.
>>> Some mails and discussion in the last days gives me now the impression that
>>> this was wrong and (at least some of) you are eager to leave the toolserver 
>>> as
>>> soon as possible.
>>> There is no point to beg the WMDE for new hardware and to invest much more
>>> time if 2 weeks after Labs is "ready" the toolserver will be empty. For this
>>> reason I created a survey at [1] that starts at midnight. Please take a 
>>> moment
>>> of your time and place your nick in the section that suits you.
>
>>> Sincerely,
>>> DaB.
>
>>> [1] https://wiki.toolserver.org/view/Labs-Moving-Survey
>
>> I wish there were an option saying "move when XXX and YYY features are
>> available and / or provided better on Labs".
>
> That's "move as soon as possible".

That's not exactly the same, especially when I add the clause
"provided better on Labs".

When some features I require are poorly available on Labs, it's still
"possible to move", but in the case that, if I decide to move, I have
to - for example - work around many issues on Labs, or have some more
difficult development work to do in order to utilize those features on
Labs, I'll still still stay on Toolserver.

-Liangent

> Tim
>
>
> ___
> Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
> https://lists.wikimedia.org/mailman/listinfo/toolserver-l
> Posting guidelines for this list: 
> https://wiki.toolserver.org/view/Mailing_list_etiquette

___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Survey: Moving to Labs

[seth]

Hi!

On 01.05.2013 22:02, Liangent wrote:
> On Thu, May 2, 2013 at 3:53 AM, DaB.  wrote:
>> [1] https://wiki.toolserver.org/view/Labs-Moving-Survey
> 
> I wish there were an option saying "move when XXX and YYY features are
> available and / or provided better on Labs".

Actually I's say "Hey, it's a wiki!" or maybe I would just add your
preferred option, but unfortunately I still can't login at that wiki,
see 

Bye
seth

___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Survey: Moving to Labs

[Tim Landscheidt]

(anonymous) wrote:

>> until now I had the impression that we (you, the authors, and me) fight
>> together against WMF and WMDE for keeping the Toolserver and against Labs.
>> Some mails and discussion in the last days gives me now the impression that
>> this was wrong and (at least some of) you are eager to leave the toolserver 
>> as
>> soon as possible.
>> There is no point to beg the WMDE for new hardware and to invest much more
>> time if 2 weeks after Labs is "ready" the toolserver will be empty. For this
>> reason I created a survey at [1] that starts at midnight. Please take a 
>> moment
>> of your time and place your nick in the section that suits you.

>> Sincerely,
>> DaB.

>> [1] https://wiki.toolserver.org/view/Labs-Moving-Survey

> I wish there were an option saying "move when XXX and YYY features are
> available and / or provided better on Labs".

That's "move as soon as possible".

Tim


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Survey: Moving to Labs

[Aaron Halfaker]

+1


On Wed, May 1, 2013 at 3:02 PM, Liangent  wrote:

> On Thu, May 2, 2013 at 3:53 AM, DaB.  wrote:
> > Hello all,
> >
> > until now I had the impression that we (you, the authors, and me) fight
> > together against WMF and WMDE for keeping the Toolserver and against
> Labs.
> > Some mails and discussion in the last days gives me now the impression
> that
> > this was wrong and (at least some of) you are eager to leave the
> toolserver as
> > soon as possible.
> > There is no point to beg the WMDE for new hardware and to invest much
> more
> > time if 2 weeks after Labs is "ready" the toolserver will be empty. For
> this
> > reason I created a survey at [1] that starts at midnight. Please take a
> moment
> > of your time and place your nick in the section that suits you.
> >
> > Sincerely,
> > DaB.
> >
> >
> > [1] https://wiki.toolserver.org/view/Labs-Moving-Survey
>
> I wish there were an option saying "move when XXX and YYY features are
> available and / or provided better on Labs".
>
> -Liangent
>
> ___
> Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
> https://lists.wikimedia.org/mailman/listinfo/toolserver-l
> Posting guidelines for this list:
> https://wiki.toolserver.org/view/Mailing_list_etiquette
___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Survey: Moving to Labs

[Liangent]

On Thu, May 2, 2013 at 3:53 AM, DaB.  wrote:
> Hello all,
>
> until now I had the impression that we (you, the authors, and me) fight
> together against WMF and WMDE for keeping the Toolserver and against Labs.
> Some mails and discussion in the last days gives me now the impression that
> this was wrong and (at least some of) you are eager to leave the toolserver as
> soon as possible.
> There is no point to beg the WMDE for new hardware and to invest much more
> time if 2 weeks after Labs is "ready" the toolserver will be empty. For this
> reason I created a survey at [1] that starts at midnight. Please take a moment
> of your time and place your nick in the section that suits you.
>
> Sincerely,
> DaB.
>
>
> [1] https://wiki.toolserver.org/view/Labs-Moving-Survey

I wish there were an option saying "move when XXX and YYY features are
available and / or provided better on Labs".

-Liangent

___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

[Toolserver-l] Survey: Moving to Labs

[DaB.]

Hello all,

until now I had the impression that we (you, the authors, and me) fight 
together against WMF and WMDE for keeping the Toolserver and against Labs. 
Some mails and discussion in the last days gives me now the impression that 
this was wrong and (at least some of) you are eager to leave the toolserver as 
soon as possible.
There is no point to beg the WMDE for new hardware and to invest much more 
time if 2 weeks after Labs is "ready" the toolserver will be empty. For this 
reason I created a survey at [1] that starts at midnight. Please take a moment 
of your time and place your nick in the section that suits you.

Sincerely,
DaB.

 
[1] https://wiki.toolserver.org/view/Labs-Moving-Survey

-- 
Userpage: [[:w:de:User:DaB.]] — PGP: 0x2d3ee2d42b255885


signature.asc
Description: This is a digitally signed message part.
___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Toolserver --> Labs

[Marc A. Pelletier]

On 04/30/2013 11:10 PM, Jeremy Baron wrote:
> I don't know what peter/asher had planned for the new Maria world.

Yes, the fact that there are a couple of near-equivalent ways of doing
it is part of the reason why we haven't been all that explicit yet -- I
want to do some testing first to find the best solution before we
encourage people to use it; there's little point in having everyone
start doing it one way just to come back a few weeks later to announce
"well, we're doing this another way after all".  :-)

-- Marc


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Toolserver --> Labs

[DaB.]

Hello,
At Wednesday 01 May 2013 14:46:08 DaB. wrote:
>  The Toolserver had a tendency to make breaking changes

sorry, I have to disagree here. We are very backwards-compatible. We still 
support a Solaris-login-server just because people are too lazzy to convert 
their stuff to Linux, we still support 2 variants of cron because the users can 
not decide which one to use. We have let people run non-SGE-task 2 YEARS after 
River announced the usage of SGE.
If our little changes are too much for you, than a moving to Labs will be out 
of question for you.

Sincerely,
DaB.

-- 
Userpage: [[:w:de:User:DaB.]] — PGP: 0x2d3ee2d42b255885


signature.asc
Description: This is a digitally signed message part.
___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette