Re: [Wikitech-l] A potential land mine

[Tim Starling]

dan nessett wrote:
> Sprinkling the computation of $IP all over the place is just
> looking for trouble. At some point the code used to make this
> computation may diverge and you will have bugs introduced. My first
> reaction to this problem was to wonder why these files didn't just
> require LocalSettings.php. However, since it is a fairly complex
> file doing so might not be desirable because: 1) there are values
> in LocalSettings.php that would interfere with values in these
> files, 2) there is some ordering problem that might occur, or 3)
> there are performance considerations.

No, the reason is because LocalSettings.php is in the directory
pointed to by $IP, so you have to work out what $IP is before you can
include it.

Web entry points need to locate WebStart.php, and command line scripts
need to locate maintenance/commandLine.inc. Then either of those two
entry scripts can locate the rest of MediaWiki.

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] site requests for Hungarian Wikipedia

[Tisza Gergő]

Rob Halsell  wikimedia.org> writes:

> All outstanding requests in the original email for this thread have been
> addressed and processed to completion.

The urgent one (autoreview not working,
https://bugzilla.wikimedia.org/show_bug.cgi?id=19885 ) is still unsolved, with
no activity for days. Sorry for being obstinate about this, but it really is
important. It took a lot of effort to convince huwiki patrollers that flagged
revisions will be good for them and get them to use it regularly, and now it's
been a huge amount of extra work for them, for two weeks. They can't keep up
with the load for long, and I'm worried they will get fed up, and the current
technical failure will turn into a social failure, and that one is much harder
to fix.

> Now, I am nearly always in IRC, even when I am not at the keyboard.
> While it is not a permanent solution, everyone should feel free to PM me
> with any requests that seem to have been outstanding and ready for
> processing a bit too long.  I may not be able to get to them right that
> second, but I am trying my best!  =]

I contacted r...@freenode, but got no reply. I'm not sure it was you though,
since the user did not identify himself to nickserv, and was not on any
Wikimedia-related channel. (The hostmask was n=...@5ad4934d.bb.sky.com.)
If it was you, you should probably set your client to autoident so people can be
sure it is you they are talking to. If it wasn't, you can tell nickserv to guard
your nick more aggressively by /msg nickserv set enforce.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] A potential land mine

[dan nessett]

For various reasons I have noticed that several files independently compute the 
value of $IP. For example, maintenance/Command.inc and includes/WebStart.php 
both calculate its value. One would expect this value to be computed in one 
place only and used globally. The logical place is LocalSettings.php.

Sprinkling the computation of $IP all over the place is just looking for 
trouble. At some point the code used to make this computation may diverge and 
you will have bugs introduced. My first reaction to this problem was to wonder 
why these files didn't just require LocalSettings.php. However, since it is a 
fairly complex file doing so might not be desirable because: 1) there are 
values in LocalSettings.php that would interfere with values in these files, 2) 
there is some ordering problem that might occur, or 3) there are performance 
considerations.

If it isn't possible and or desirable to replace the distributed computation of 
$IP with require_once('LocalSettings.php'), then I suggest breaking 
LocalSettings into two parts, say LocalSettingsCore.php and 
LocalSettingsNonCore.php (I am sure someone can come up with better names). 
LocalSettingsCore.php would contain only those calculations and definitions 
that do not interfere with the core MW files. LocalSettingsNonCore.php would 
contain everything else now in LocalSettings.php. Obviously, the first 
candidate for inclusion in LocalSettingsCore.php is the computation of $IP. 
Once such a separation is carried out, files like maintenance/Command.inc and 
includes/WebStart.php can require_once('LocalSettingsCore.php') instead of 
independently computing $IP.


  

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How sort key works?

[Helder Geovane Gomes de Lima]

2009/8/10 Aryeh Gregor

>

> We could break ties by appending the page title to custom sort keys,
> if this is a problem.
>

I think it would be good! =)

(We actually have manually used "*{{PAGENAME}}" for a while... =S)

Helder
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How sort key works?

[Aryeh Gregor]

On Mon, Aug 10, 2009 at 4:07 PM, Brion Vibber wrote:
> To clarify, here's the information that's available when sorting a
> category membership list:
>
> * category name (fixed, since we're looking at a particular category)
> * sort key (normally the page title, unless you overrode it)
> * page ID (roughly corresponds to page creation time)
>
> The page title can only be applied to the sorting if it's actually *in*
> the sort key. If you've overridden it, then *only* the sort key you
> provided will have any relevance in ordering; page ID will serve as a
> 'tiebreaker' but isn't really predictable.

We could break ties by appending the page title to custom sort keys,
if this is a problem.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How sort key works?

[Brion Vibber]

On 8/10/09 12:18 PM, Roan Kattouw wrote:
> 2009/8/10 Helder Geovane Gomes de Lima:
>> 1) What is the criteria for ordering the pages when the sort key of two
>> pages are the same?
> I think they're ordered by page ID, but I'm not sure. For all
> practical purposes, the ordering of pages with the same sortkey is
> undefined.

To clarify, here's the information that's available when sorting a 
category membership list:

* category name (fixed, since we're looking at a particular category)
* sort key (normally the page title, unless you overrode it)
* page ID (roughly corresponds to page creation time)

The page title can only be applied to the sorting if it's actually *in* 
the sort key. If you've overridden it, then *only* the sort key you 
provided will have any relevance in ordering; page ID will serve as a 
'tiebreaker' but isn't really predictable.

-- brion

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How sort key works?

[Roan Kattouw]

2009/8/10 Helder Geovane Gomes de Lima :
> 1) What is the criteria for ordering the pages when the sort key of two
> pages are the same?
I think they're ordered by page ID, but I'm not sure. For all
practical purposes, the ordering of pages with the same sortkey is
undefined.

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] How sort key works?

[Helder Geovane Gomes de Lima]

Hi!

Some time ago I was categorizing some pages at pt.wikibooks and I found the
following curious situation:
I've used the code [[Category:Test|*]] in these pages:
http://pt.wikibooks.org/w/index.php?title=User:Heldergeovane/*Bi*
ologia_celular/Índice&action=edit
http://pt.wikibooks.org/w/index.php?title=User:Heldergeovane/*Bo*
nsai_no_Brasil:_Índice&action=edit

So, we expect:
* Both pages should appear at "Category:Test" under "*", and
* "User:Heldergeovane/B*i*ologia_celular/Índice" should be before
"User:Heldergeovane/B*o*nsai_no_Brasil:_Índice" (since "i" comes first than
"o").

However, what we found at
http://pt.wikibooks.org/w/index.php?title=Category:Test
is the reverse order.

1) What is the criteria for ordering the pages when the sort key of two
pages are the same?
2) Is there anything wrong with the ordering of the two pages above?

Helder
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Reliability of rev_id as order maintaining in enwiki

[Charlotte Webb]

On Mon, Aug 10, 2009 at 12:10 PM, Aryeh
Gregor wrote:
> This is usually a safe-ish assumption, though, as long as occasional
> misordering is acceptable.  Don't we generate next/previous revision
> links in some places based on rev_id?

In the diff view, for one. Weird ones like this are very common in old articles:

http://en.wikipedia.org/w/index.php?title=Bill_Clinton&oldid=238014&diff=prev

—C.W.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Reliability of rev_id as order maintaining in enwiki

[Aryeh Gregor]

On Mon, Aug 10, 2009 at 12:36 PM, Brion Vibber wrote:
> Yes, in the sense that they were added to the database afterwards.
>
> No, in the sense that rev_timestamp may not always show a later date for
> a later rev_id:
>
> * Page histories imported from pre-conversion UseModWiki archives
> * Anything imported via Special:Import
> * Anything undeleted before ar_rev_id column was added
> * Anything saved on a server that had a mis-configured clock

Plus there's a race condition in generating the timestamps.  They're
generated slightly before the row is actually inserted, so if two
revisions were saved at almost exactly the same time, it's possible
for one to have a timestamp one second later but a lower id.

This is usually a safe-ish assumption, though, as long as occasional
misordering is acceptable.  Don't we generate next/previous revision
links in some places based on rev_id?

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Reliability of rev_id as order maintaining in enwiki

[Brion Vibber]

On 8/10/09 9:28 AM, Aaron L Halfaker wrote:
> I'm using data from a snapshot of the English Wikipedia and would like
> to run a query similar to the following:
>
> SELECT * FROM revision
> WHERE rev_id>  some_rev_id;
>
> Can I be confident that all revisions returned were saved after some_rev_id?

Yes, in the sense that they were added to the database afterwards.

No, in the sense that rev_timestamp may not always show a later date for 
a later rev_id:

* Page histories imported from pre-conversion UseModWiki archives
* Anything imported via Special:Import
* Anything undeleted before ar_rev_id column was added
* Anything saved on a server that had a mis-configured clock

-- brion

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Reliability of rev_id as order maintaining in enwiki

[Aaron L Halfaker]

I'm using data from a snapshot of the English Wikipedia and would like
to run a query similar to the following:

SELECT * FROM revision
WHERE rev_id > some_rev_id;

Can I be confident that all revisions returned were saved after some_rev_id?

Thanks!
-Aaron

P.S. I have considered using rev_timestamp and would like to avoid that
if it is possible.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l