On 11/28/2012 16:48, janI wrote:
This is my final sql script for location old users without contributions,
can someone please verify the script ?
The script only collect user_id, user_name, user_registration in the table
xmaint_uids.
It is running right now, and once finished (in the morning
On Thu, Nov 29, 2012 at 9:17 AM, janI j...@apache.org wrote:
Yes I locked it hard down, on request from the communityI had to use
the big knife to be fast.
I am looking into how to open for sysop, but my concern is that at least 2
spam accounts (Or more correctly 2 that fit the pattern)
You might be very right, the user that changed the rights is created back
in 2007, and is by the way one of user destined for deletion.
Jan.
On 29 November 2012 15:29, Rob Weir robw...@apache.org wrote:
On Thu, Nov 29, 2012 at 9:17 AM, janI j...@apache.org wrote:
Yes I locked it hard down,
On Thu, Nov 29, 2012 at 3:29 PM, Rob Weir robw...@apache.org wrote:
On Thu, Nov 29, 2012 at 9:17 AM, janI j...@apache.org wrote:
Yes I locked it hard down, on request from the communityI had to use
the big knife to be fast.
I am looking into how to open for sysop, but my concern is that
Except the fact that the table logging has relative huge holes in it, and I
do not know if it has something to do with the different moves.
However this does not really bother me, what bothers me more is that the
ooo-wiki VM is so weak (compared to my notebook) that a lot of my special
On 29/11/2012 janI wrote:
ooo-wiki VM is so weak (compared to my notebook) that a lot of my special
select/join statements timed out...and the just because I have a simple
where clause where user_id in (select user_id from wiki_maint_uids)
I only had a quick look yesterday and I cannot check
Thanks I did not know that LEFT JOIN and JOIN has different speeds on inodb
tables. I made the fast fix, and split xmaint_uids into smaller tables, and
is running now.
BUT I am dead nervous of deleting wrong data !! so the review in general
would be nice.
I have also decided to post the user
On 11/29/2012 13:19, janI wrote:
Thanks I did not know that LEFT JOIN and JOIN has different speeds on inodb
tables. I made the fast fix, and split xmaint_uids into smaller tables, and
is running now.
BUT I am dead nervous of deleting wrong data !! so the review in general
would be nice.
I
Jan,
On 01.11.30 02:19am, janI said:
Thanks I did not know that LEFT JOIN and JOIN has different speeds on inodb
tables. I made the fast fix, and split xmaint_uids into smaller tables, and
is running now.
BUT I am dead nervous of deleting wrong data !! so the review in general
would be
On 27/11/2012 23:23, janI wrote:
On 27 November 2012 22:53, Andrea Pescetti wrote:
On 25/11/2012 jan iversen wrote:
I agree we should have this stuff versioned (actually, all configuration
files on the Apache infrastructure are versioned, but in distinct SVN
repository). I'll check with Infra
On 28 November 2012 18:47, Andrea Pescetti pesce...@apache.org wrote:
On 27/11/2012 23:23, janI wrote:
On 27 November 2012 22:53, Andrea Pescetti wrote:
On 25/11/2012 jan iversen wrote:
I agree we should have this stuff versioned (actually, all configuration
files on the Apache
On 25/11/2012 jan iversen wrote:
a) In order to keep track of all php/apache/mysql changes to wiki, I will
make a directory wiki-maintenance in SVN on level with trunk.
Which SVN? I wouldn't put it in
https://svn.apache.org/repos/asf/openoffice/
since it's already dirty enough (mixing
On 27 November 2012 22:53, Andrea Pescetti pesce...@apache.org wrote:
On 25/11/2012 jan iversen wrote:
a) In order to keep track of all php/apache/mysql changes to wiki, I will
make a directory wiki-maintenance in SVN on level with trunk.
Which SVN? I wouldn't put it in
https
/apache/mysql changes to wiki, I will
make a directory wiki-maintenance in SVN on level with trunk. Currently
we do not really know what has been changed, and with the upgrade we have a
nice opportunity of documenting all changes, so it is easier for future
administrators. I know there is a very good page
consensus on the following items:
a) In order to keep track of all php/apache/mysql changes to wiki, I will
make a directory wiki-maintenance in SVN on level with trunk. Currently
we do not really know what has been changed, and with the upgrade we have a
nice opportunity of documenting all changes, so
/mysql changes to wiki, I will
make a directory wiki-maintenance in SVN on level with trunk.
Currently
we do not really know what has been changed, and with the upgrade we
have a
nice opportunity of documenting all changes, so it is easier for future
administrators. I know there is a very
Where to insert is simple, but when I copied the ooo-site settings to l10n,
I was told that was wrong...so what I need is the correct google key to use.
Jan.
On 25 November 2012 17:24, C smau...@gmail.com wrote:
On Sun, Nov 25, 2012 at 5:12 PM, janI j...@apache.org wrote:
Not as urgent as
of all php/apache/mysql changes to wiki, I will
make a directory wiki-maintenance in SVN on level with trunk.
Currently
we do not really know what has been changed, and with the upgrade we
have a
nice opportunity of documenting all changes, so it is easier for future
administrators. I know
Loophole is found and blocked !!!
Yes there are spam account back from may (see my other posting in thread
spam), and I also identified about 2.000 accounts beginning 2011.
They have infected 7 tables, so I am creating an intelligent worm to unwind
their work, these tables are the core of wiki
19 matches
Mail list logo
