Brion Vibber schrieb:
> Robert Rohde wrote:
>> I must confess my understanding of replication is crude, but it seems like a
>> lot of problems might be solved if WMF could establish some form of
>> intermediate replication server that took existing databases, stripped out
>> the private bits, and t
Robert Rohde wrote:
> I must confess my understanding of replication is crude, but it seems like a
> lot of problems might be solved if WMF could establish some form of
> intermediate replication server that took existing databases, stripped out
> the private bits, and then offered the remainder fo
On Wed, Jun 17, 2009 at 12:37 PM, Andrew Garrett wrote:
> If replicating entire tables to the toolserver isn't working from a
> legal perspective, then maybe we should try something else. There are
> plenty of other problems with this approach, too.
I must confess my understanding of replication
On Wed, Jun 17, 2009 at 3:33 PM, Daniel Kinzler wrote:
> Hehe, nice hack :) But tricky when new databases get added.
No, just alter them. It will truncate all existing entries too.
> Naw, in the end, I want to get rid of the entries in recentchanges
> alltogether.
Why, other than the toolserv
On 17/06/2009, at 8:33 PM, Daniel Kinzler wrote:
> Naw, in the end, I want to get rid of the entries in recentchanges
> alltogether.
> One clean solution would to simply say that retroactive autoblocks
> become tied
> to checkuser functionality. But I suppose that, too, is a bit awkward.
I
Aryeh Gregor schrieb:
> On Wed, Jun 17, 2009 at 5:39 AM, Daniel Kinzler wrote:
>> As to disabling on Wikimedia projects: this would make things easier for the
>> toolserver mainly. We don't need this info there, and having it might
>> conceivably make WMDE the target of legal action. We can easily
Platonides schrieb:
> Daniel Kinzler wrote:
>> Not true, as explained above. Using a hook the way I proposed is a bit
>> painful
>> though. The question is if it's worth is, and if there's a better way.
>>
>> -- daniel
>
> It could replace the block class overriding doRetroactiveAutoblock()
Righ
On Wed, Jun 17, 2009 at 5:39 AM, Daniel Kinzler wrote:
> As to disabling on Wikimedia projects: this would make things easier for the
> toolserver mainly. We don't need this info there, and having it might
> conceivably make WMDE the target of legal action. We can easily exclude
> cu_changes from r
Daniel Kinzler wrote:
> Not true, as explained above. Using a hook the way I proposed is a bit painful
> though. The question is if it's worth is, and if there's a better way.
>
> -- daniel
It could replace the block class overriding doRetroactiveAutoblock()
Robert Rohde schrieb:
>
> If the current concern is the toolserver, and the toolserver never actually
> uses this info, shouldn't it be possible to set up a process that routinely
> wiped out those records? Not an ideal solution perhaps, but the contortions
> you seem to be suggesting for the cor
On Wed, Jun 17, 2009 at 6:44 AM, Daniel Kinzler wrote:
> Andrew Garrett schrieb:
> > On 17/06/2009, at 2:26 PM, John Doe wrote:
> >> I have access to the toolserver and rcip is not available. please note
> >> that the chechuser table is created by an extension and not by
> >> mediawiki thus you ca
Andrew Garrett schrieb:
> On 17/06/2009, at 2:26 PM, John Doe wrote:
>> I have access to the toolserver and rcip is not available. please note
>> that the chechuser table is created by an extension and not by
>> mediawiki thus you cannot depend on extensions that my or may not be
>> insalled on all
John Doe schrieb:
> I have access to the toolserver and rcip is not available.
It's not available to users via the xxx_p views. it is however replicated and
available to admins, and this accessible to wmde.
> please note
> that the chechuser table is created by an extension and not by
> mediawik
2009/6/17 John Doe :
> please note
> that the chechuser table is created by an extension and not by
> mediawiki thus you cannot depend on extensions that my or may not be
> insalled on all wikis. it may be that way on MWF wikis bit mediawiki
> is not just used on MWF wikis. what you want done canno
On 17/06/2009, at 2:26 PM, John Doe wrote:
> I have access to the toolserver and rcip is not available. please note
> that the chechuser table is created by an extension and not by
> mediawiki thus you cannot depend on extensions that my or may not be
> insalled on all wikis. it may be that way on
I have access to the toolserver and rcip is not available. please note
that the chechuser table is created by an extension and not by
mediawiki thus you cannot depend on extensions that my or may not be
insalled on all wikis. it may be that way on MWF wikis bit mediawiki
is not just used on MWF wik
John Doe schrieb:
> nc the cu is an extension and not part of trunk so thst will not work
Huh, why shouldn't it? The idea was that the extension would hijack the way
Block.php looks up the past IP addresses, and does it via cu_changes. So the
IPÜs would no langer be needed in rc.
I admin though t
nc the cu is an extension and not part of trunk so thst will not work
On 6/17/09, Daniel Kinzler wrote:
> Andrew Garrett schrieb:
>> On 17/06/2009, at 10:39 AM, Daniel Kinzler wrote:
>>
>>> Hi all
>>>
>>> I wonder if the column rc_ip can be safely removed from mediawiki.
>>> As far as I
>>> know,
Andrew Garrett schrieb:
> On 17/06/2009, at 10:39 AM, Daniel Kinzler wrote:
>
>> Hi all
>>
>> I wonder if the column rc_ip can be safely removed from mediawiki.
>> As far as I
>> know, it has been superceeded by the information in cu_changes, right?
>
>
> rc_ip is used by the retroactive autob
On 17/06/2009, at 10:39 AM, Daniel Kinzler wrote:
> Hi all
>
> I wonder if the column rc_ip can be safely removed from mediawiki.
> As far as I
> know, it has been superceeded by the information in cu_changes, right?
rc_ip is used by the retroactive autoblock functionality (i.e. when a
user
Hi all
I wonder if the column rc_ip can be safely removed from mediawiki. As far as I
know, it has been superceeded by the information in cu_changes, right? So I
propose to
a) either completely remove it
b) or set $wgPutIPinRC = false per default
c) and set $wgPutIPinRC = false for wikimedia proj
21 matches
Mail list logo
