Re: [Wikitech-l] Status of 1.17 1.18
On 15 April 2011 06:53, Tim Starling tstarl...@wikimedia.org wrote: * Less hassle for non-Wikimedia users, since upgrades between major releases require more work. Extensions break, patches break, DB upgrades need to be done. People upgrade seldom. If we have one release per year it is likely that the code they upgrade to is already so old nobody remembers how it works. * Less branches to backport to. This reduces the amount of work that needs to be done to backport security fixes and other bug fixes. We drop support for branches based on time elapsed, not number of versions released. I agree with this one, although I'm not the one who feels the pain here. * Less branches to test against. If you're writing an extension that is meant to work on multiple MediaWiki versions, it will be easier if there are less versions that you need to test against, and potentially write special-case code for. On the other hand, with few releases far and between, I need to write lot of compatibility code in Translate extension to even support the latest stable release and trunk at the same time. Having branches for different releases for my extension sounds like a lot of effort to maintain them, not even speaking about supporting them. But all of this is moot, since you're proposing 3 releases per year and I'm complaining about having only one or two releases per year. Three releases would be enough for me. -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r86088]: New comment added
User DieBuche posted a comment on MediaWiki.r86088.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86088#c15979
Commit summary:
Completely rewritten table sorting script.
Fixes Bug 8028, Bug 8115, Bug 15406, Bug 17141, Bug 8732
1. Sites can specify custom collations.
The script accepts an object tableSorterCollation which contains a lookup
table, how specific characters should be treated.
For example, after setting tableSorterCollation={'ä':'ae', 'ß':'ss'}; in the
site's common.js any string containing an ä or Ä will be sorted as if it were a
'ae'.
2. Table rows can be forced to use a specific data type.
By setting class=sort-{Parsername}, the row will be parsed with the specified
algorithm. class=sort-date would force date sorting etc.
The following parsers are available: text, IPAddress, number, url, currency,
date, isoDate, usLongDate, time
3. Execution time is reduced by half or more.
Sorting a 935 row * 8 columns table:
Browser Before After
-- -
Chrome 10 90ms42ms
Safari 5115ms 48ms
Firefox 4 412ms 87ms
IE8 720ms 115ms
4. Based on the content language and the mdy vs dmy preference, the parser can
understand dates such as 17. März '11. wgMonthNames=[] and
wgMonthNamesShort=[]
in the content language and the mdy vs dmy preference are exported to js; A
table containing the following dates would be sorted correctly:
17. Jan. 01
23 Feb 1992
9.02.05
13 November 2001
14 Oktober '76
Was tested in ie6-8, chrome, safari 5, ff3 ff4
Comment:
I somehow had the feeling that data stuff would be stripped.
I was hesitant to close them because of the revert1.18 tag, will it only be
reverted in the future REL1.18 branch?
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86088]: New comment added
User Nikerabbit posted a comment on MediaWiki.r86088.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86088#c15980
Commit summary:
Completely rewritten table sorting script.
Fixes Bug 8028, Bug 8115, Bug 15406, Bug 17141, Bug 8732
1. Sites can specify custom collations.
The script accepts an object tableSorterCollation which contains a lookup
table, how specific characters should be treated.
For example, after setting tableSorterCollation={'ä':'ae', 'ß':'ss'}; in the
site's common.js any string containing an ä or Ä will be sorted as if it were a
'ae'.
2. Table rows can be forced to use a specific data type.
By setting class=sort-{Parsername}, the row will be parsed with the specified
algorithm. class=sort-date would force date sorting etc.
The following parsers are available: text, IPAddress, number, url, currency,
date, isoDate, usLongDate, time
3. Execution time is reduced by half or more.
Sorting a 935 row * 8 columns table:
Browser Before After
-- -
Chrome 10 90ms42ms
Safari 5115ms 48ms
Firefox 4 412ms 87ms
IE8 720ms 115ms
4. Based on the content language and the mdy vs dmy preference, the parser can
understand dates such as 17. März '11. wgMonthNames=[] and
wgMonthNamesShort=[]
in the content language and the mdy vs dmy preference are exported to js; A
table containing the following dates would be sorted correctly:
17. Jan. 01
23 Feb 1992
9.02.05
13 November 2001
14 Oktober '76
Was tested in ie6-8, chrome, safari 5, ff3 ff4
Comment:
It means that if it works, it will stay in trunk and future releases, but it
will not go into the 1.18 release. data- attributes has been allowed for a
while already.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85906]: New comment added, and revision status changed
User Freakolowsky changed the status of MediaWiki.r85906. Old Status: new New Status: fixme User Freakolowsky also posted a comment on MediaWiki.r85906. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85906#c15981 Commit summary: Change the duplicateTableStructure() to use the original names. It is now duplicateTableStructure() duty to addIdentifierQuotes() them. Fixed bug for mysql 4.1 where the new name would be quoted twice. Always quote identifier in Oracle, doing otherwise seems a bug (can someone confirm?) Comment: This will not fly!!! You are reading documentation for Oracle 10g (10.2) ... the current state of Oracle code in MW is written for 9i (9.2) which has very limited (i.e. some but buggy) support for object naming in quotes and most of people i know use 9i for MW. So could you please STOP trying to stuff these quotes in the code every 2 months. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86088]: New comment added, and revision status changed
User DieBuche changed the status of MediaWiki.r86088.
Old Status: fixme
New Status: new
User DieBuche also posted a comment on MediaWiki.r86088.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86088#c15982
Commit summary:
Completely rewritten table sorting script.
Fixes Bug 8028, Bug 8115, Bug 15406, Bug 17141, Bug 8732
1. Sites can specify custom collations.
The script accepts an object tableSorterCollation which contains a lookup
table, how specific characters should be treated.
For example, after setting tableSorterCollation={'ä':'ae', 'ß':'ss'}; in the
site's common.js any string containing an ä or Ä will be sorted as if it were a
'ae'.
2. Table rows can be forced to use a specific data type.
By setting class=sort-{Parsername}, the row will be parsed with the specified
algorithm. class=sort-date would force date sorting etc.
The following parsers are available: text, IPAddress, number, url, currency,
date, isoDate, usLongDate, time
3. Execution time is reduced by half or more.
Sorting a 935 row * 8 columns table:
Browser Before After
-- -
Chrome 10 90ms42ms
Safari 5115ms 48ms
Firefox 4 412ms 87ms
IE8 720ms 115ms
4. Based on the content language and the mdy vs dmy preference, the parser can
understand dates such as 17. März '11. wgMonthNames=[] and
wgMonthNamesShort=[]
in the content language and the mdy vs dmy preference are exported to js; A
table containing the following dates would be sorted correctly:
17. Jan. 01
23 Feb 1992
9.02.05
13 November 2001
14 Oktober '76
Was tested in ie6-8, chrome, safari 5, ff3 ff4
Comment:
Ok, old code is removed and I added support for data-sort-value moved the
other one to data-sort-type
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86105]: New comment added
User Peachey88 posted a comment on MediaWiki.r86105. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86105#c15983 Commit summary: Useful extension by Milan allowing files to be attached to pages Comment: FileAttach.php: pre+ 'url' = 'http://www.mediawiki.org/wiki/FileAttach',/pre Ideally should be 'http://www.mediawiki.org/wiki/Extension:FileAttach', Yes we can do redirects to it in the main namespace but that is just messy. Also the page should be created on wiki (which I might do in a moment). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86105]: New comment added
User Peachey88 posted a comment on MediaWiki.r86105. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86105#c15984 Commit summary: Useful extension by Milan allowing files to be attached to pages Comment: pre+ 'description' = 'Adds class attributes to links based on their category',/pre Also seems to be wrong. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Status of 1.17 1.18
2011/4/15 Tim Starling tstarl...@wikimedia.org: My preference is for 2 to 3 major releases per year. We branched 1.17 in December and we're looking at doing a release in April. So a 4 month cycle would imply branching 1.18 in April and releasing in August. I don't think having 4 or 5 major releases per year would serve anyone particularly well. A slower release cadence means: I can get on board with having 3 releases per year, but I'll reiterate that 3 months, let alone 4, between branching and releasing is too long. Yes, 1.17 took 4 months to stabilize, but it was 10 months' worth of code, so that's a 1:2.5 ratio. Interpolating that suggests that a release with 4 months' worth of code can be prepared in less than 2 months, and I think that once code review is organized properly such that large backlogs don't happen anymore (we had a very large backlog for 1.17 and I think we'll have a comparable one, considering the difference in elapsed time, for 1.18, but I'd really like to have this organized properly for 1.19 or 1.20), we can do better than that. Instead, you're proposing a 1:1 workflow where, at any given point in time, we always have a release branch that's being stabilized, which means we have to perpetually maintain three branches (trunk, deployment, release) instead of two, and are always in the process of preparing a release. I don't like that idea, and I think it's unnecessary. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r86041]: New comment added
User Catrope posted a comment on MediaWiki.r86041. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/86041#c15985 Commit summary: r86001, now with less scariness :P I took out the delete action and did purge instead, which is a much more self-contained action-with-a-form. Also implement a few changes suggested by Brion on IRC last night. Comment: Provisionally tagging revert1.18, per Happy-melon this is 1.19 material. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86041]: New comment added
User Happy-melon posted a comment on MediaWiki.r86041. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86041#c15986 Commit summary: r86001, now with less scariness :P I took out the delete action and did purge instead, which is a much more self-contained action-with-a-form. Also implement a few changes suggested by Brion on IRC last night. Comment: It redirects because it otherwise doesn't know what else to do; since things are now properly separated viewing the page on action=purge doesn't make sense. I suppose it could call ttAction::factory( 'view', $this-page )-show()/tt internally, but that seems rather kludgish. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85786]: New comment added, and revision status changed
User Freakolowsky changed the status of MediaWiki.r85786. Old Status: fixme New Status: new User Freakolowsky also posted a comment on MediaWiki.r85786. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85786#c15987 Commit summary: * fix as per brion's comment on r85669 Comment: used quoted parameter in r86112 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85906]: New comment added, and revision status changed
User Freakolowsky changed the status of MediaWiki.r85906. Old Status: fixme New Status: new User Freakolowsky also posted a comment on MediaWiki.r85906. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85906#c15988 Commit summary: Change the duplicateTableStructure() to use the original names. It is now duplicateTableStructure() duty to addIdentifierQuotes() them. Fixed bug for mysql 4.1 where the new name would be quoted twice. Always quote identifier in Oracle, doing otherwise seems a bug (can someone confirm?) Comment: Quotes gone ... once again. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86105]: New comment added
User Reedy posted a comment on MediaWiki.r86105.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86105#c15989
Commit summary:
Useful extension by Milan allowing files to be attached to pages
Comment:
pre
+ function __construct() {
+ global $wgHooks;
+ $wgHooks['BeforePageDisplay'][] = $this;
+ $wgHooks['UploadForm:initial'][] = array( $this,
'onUploadFormInitial' );
+ $wgHooks['UploadForm:BeforeProcessing'][] = array( $this,
'onUploadFormBeforeProcessing' );
+ $wgHooks['SkinTemplateTabs'][] = $this;
+ $wgHooks['SkinTemplateNavigation'][] = $this;
+ }
/pre
Shouldn't all of those be arrays, rather than just passing a class reference
and no target method?
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86113]: New comment added
User MaxSem posted a comment on MediaWiki.r86113. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86113#c15990 Commit summary: * added E_DEPRECATED into wfSupressWarnings merge into 1.17 if required PHP version will be 5.3+ Comment: Why? E_DEPRECATED helps a lot. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86113]: New comment added
User MaxSem posted a comment on MediaWiki.r86113. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86113#c15992 Commit summary: * added E_DEPRECATED into wfSupressWarnings merge into 1.17 if required PHP version will be 5.3+ Comment: Consider the following: pre wfSuppressWarnings(); $db = wfGetDB( DB_SLAVE ); wfRestoreWarnings(); /pre Why don't you want to be able to be informed about such problems? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86113]: New comment added, and revision status changed
User Happy-melon changed the status of MediaWiki.r86113. Old Status: new New Status: fixme User Happy-melon also posted a comment on MediaWiki.r86113. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86113#c15993 Commit summary: * added E_DEPRECATED into wfSupressWarnings merge into 1.17 if required PHP version will be 5.3+ Comment: PHP 5.3 is not required for 1.17 or (currently) 1.18, so this needs B/C for PHP 5.2 if ttE_DEPRECATED/tt is not defined. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86113]: New comment added, and revision status changed
User Freakolowsky changed the status of MediaWiki.r86113. Old Status: fixme New Status: new User Freakolowsky also posted a comment on MediaWiki.r86113. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86113#c15994 Commit summary: * added E_DEPRECATED into wfSupressWarnings merge into 1.17 if required PHP version will be 5.3+ Comment: Specifically because of wfDl function which drops deprecated warning messages into the page and generated LocalSettings.php file in the installer. The other options would be to either make something like wfRealySupressWarnings which would include E_DEPRECATED or remove call of dl() function completely. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86088]: New comment added
User Helder.wiki posted a comment on MediaWiki.r86088.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86088#c15996
Commit summary:
Completely rewritten table sorting script.
Fixes Bug 8028, Bug 8115, Bug 15406, Bug 17141, Bug 8732
1. Sites can specify custom collations.
The script accepts an object tableSorterCollation which contains a lookup
table, how specific characters should be treated.
For example, after setting tableSorterCollation={'ä':'ae', 'ß':'ss'}; in the
site's common.js any string containing an ä or Ä will be sorted as if it were a
'ae'.
2. Table rows can be forced to use a specific data type.
By setting class=sort-{Parsername}, the row will be parsed with the specified
algorithm. class=sort-date would force date sorting etc.
The following parsers are available: text, IPAddress, number, url, currency,
date, isoDate, usLongDate, time
3. Execution time is reduced by half or more.
Sorting a 935 row * 8 columns table:
Browser Before After
-- -
Chrome 10 90ms42ms
Safari 5115ms 48ms
Firefox 4 412ms 87ms
IE8 720ms 115ms
4. Based on the content language and the mdy vs dmy preference, the parser can
understand dates such as 17. März '11. wgMonthNames=[] and
wgMonthNamesShort=[]
in the content language and the mdy vs dmy preference are exported to js; A
table containing the following dates would be sorted correctly:
17. Jan. 01
23 Feb 1992
9.02.05
13 November 2001
14 Oktober '76
Was tested in ie6-8, chrome, safari 5, ff3 ff4
Comment:
Isn't tttableSorterCollation/tt something that should go into
ttmw.config.get( ... )/tt?
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86105]: New comment added, and revision status changed
User Nikerabbit changed the status of MediaWiki.r86105.
Old Status: new
New Status: fixme
User Nikerabbit also posted a comment on MediaWiki.r86105.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86105#c15997
Commit summary:
Useful extension by Milan allowing files to be attached to pages
Comment:
It works that way too. It will call $that-onHookName(). But more importantly
those should be registered on the main level and use static methods.
+if( $attachto = $wgRequest-getText( 'attachto' ) ) {
+ $out-mBodytext = str_replace( /form, input type=\hidden\
name=\attachto\ value=\$attachto\ //form, $out-mBodytext );
Somebody forgot the escaping?
Title::newFromText( 'Upload', NS_SPECIAL )
Should use SpecialPage::getTitleFor( 'Upload' ) or similar.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85876]: New comment added, and revision status changed
User Nikerabbit changed the status of MediaWiki.r85876. Old Status: new New Status: fixme User Nikerabbit also posted a comment on MediaWiki.r85876. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85876#c15998 Commit summary: (bug 13879) Special:Emailuser now asks for suitable target user if called without. Comment: Use wrapWikiMsg here: +$wgOut-addHtml ( 'p class=error' . wfMessage( $ret )-parse() . '/p' ); I think this is very poor usability still. It should provide the full form immediately with incremental user name search and immediate feedback if the user can or cannot be emailed. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85887]: New comment added
User Nikerabbit posted a comment on MediaWiki.r85887. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85887#c15999 Commit summary: Update wording for messages added in r85976. Comment: r85976 should be r85876. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85922]: New comment added
User Nikerabbit posted a comment on MediaWiki.r85922. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85922#c16000 Commit summary: Comment: pre [15-Apr-2011 09:05:06] PHP Notice: Undefined index: type in /www/w/includes/parser/Parser.php on line 1056 [15-Apr-2011 09:05:06] PHP Notice: Undefined index: type in /www/w/includes/parser/Parser.php on line 1070 [15-Apr-2011 09:05:06] PHP Notice: Undefined index: type in /www/w/includes/parser/Parser.php on line 1078 [15-Apr-2011 09:05:06] PHP Notice: Undefined index: type in /www/w/includes/parser/Parser.php on line 1086 [15-Apr-2011 09:05:06] PHP Notice: Undefined index: type in /www/w/includes/parser/Parser.php on line 1094 /pre ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85922]: New comment added
User DieBuche posted a comment on MediaWiki.r85922. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85922#c16001 Commit summary: Comment: Do you have the offending code? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85922]: New comment added
User DieBuche posted a comment on MediaWiki.r85922. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85922#c16002 Commit summary: Comment: (Clarify: The wikitext that triggered it) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Status of 1.17 1.18
2011/4/15 Tim Starling tstarl...@wikimedia.org: That's a fair point. I didn't mean to propose a 1:1 workflow, I meant to just make a point about release schedules. OK. If your main point was to say that we should branch 1.18 in April and 1.19 in August, I'm cool with that. Releasing too infrequently is bad, as we saw with 1.17, but you make solid points to support the notion that releasing too frequently introduces problems of its own, and that we should find middle ground. Speaking in terms of release cycle length, I think that 4-6 months (2-3 releases/yr) is a bit long and 3-4 months (3-4 releases/yr) is better, but I'm sure we can work out a number. Your point that release cycle length should be consciously and carefully decided on is a very good one, and I'm sorry I hijacked it with my release latency argument. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85922]: New comment added
User Nikerabbit posted a comment on MediaWiki.r85922. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85922#c16003 Commit summary: Comment: Of course not, since debugging PHP is such a pain. However, if it helps you I can try to match the error timestamps into requests and find the code that way. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85922]: New comment added
User DieBuche posted a comment on MediaWiki.r85922. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85922#c16004 Commit summary: Comment: I think that would be helpful. I'd guess it's something like an empty row or cell, but I can't seem to find something that triggers it ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85922]: New comment added
User Nikerabbit posted a comment on MediaWiki.r85922. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85922#c16005 Commit summary: Comment: http://translatewiki.net/sw/User:Ahloubadar ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86103]: Revision status changed
User Catrope changed the status of MediaWiki.r86103. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/86103#c0 Commit summary: added explanation of the BeforeWelcomeCreation hook ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86011]: Revision status changed
User Catrope changed the status of MediaWiki.r86011. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/86011#c0 Commit summary: Created BeforeWelcomeCreation hook to be run before any welcome message gets displayed ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86054]: New comment added
User Catrope posted a comment on MediaWiki.r86054. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/86054#c16006 Commit summary: Added wrapper mw.api() for API calls Comment: It would be nice if the wrapper also allow POST requests. You should also talk to Neil, who has written (or inherited, or rewritten, I'm not sure) a larger mw.api library. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86114]: Revision status changed
User ^demon changed the status of MediaWiki.r86114. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86114#c0 Commit summary: Followup r86105, svn:eol-style native ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85364]: Revision status changed
User ^demon changed the status of MediaWiki.r85364. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85364#c0 Commit summary: Fix many missing commas Part of bug 28382 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86088]: New comment added
User Catrope posted a comment on MediaWiki.r86088.
Full URL:
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/86088#c16007
Commit summary:
Completely rewritten table sorting script.
Fixes Bug 8028, Bug 8115, Bug 15406, Bug 17141, Bug 8732
1. Sites can specify custom collations.
The script accepts an object tableSorterCollation which contains a lookup
table, how specific characters should be treated.
For example, after setting tableSorterCollation={'ä':'ae', 'ß':'ss'}; in the
site's common.js any string containing an ä or Ä will be sorted as if it were a
'ae'.
2. Table rows can be forced to use a specific data type.
By setting class=sort-{Parsername}, the row will be parsed with the specified
algorithm. class=sort-date would force date sorting etc.
The following parsers are available: text, IPAddress, number, url, currency,
date, isoDate, usLongDate, time
3. Execution time is reduced by half or more.
Sorting a 935 row * 8 columns table:
Browser Before After
-- -
Chrome 10 90ms42ms
Safari 5115ms 48ms
Firefox 4 412ms 87ms
IE8 720ms 115ms
4. Based on the content language and the mdy vs dmy preference, the parser can
understand dates such as 17. März '11. wgMonthNames=[] and
wgMonthNamesShort=[]
in the content language and the mdy vs dmy preference are exported to js; A
table containing the following dates would be sorted correctly:
17. Jan. 01
23 Feb 1992
9.02.05
13 November 2001
14 Oktober '76
Was tested in ie6-8, chrome, safari 5, ff3 ff4
Comment:
pre
+ #$localDateFormats = $wgContLang-getDateFormats();
+ #$localPreferedFormat =
$localDateFormats[$wgContLang-getDefaultDateFormat().' date'];
+
/pre
Please don't introduce commented-out code. There's another commented-out line a
few lines down.
pre
+ $monthNames = array('');
+ $monthNamesShort = array('');
+ for ($i=1; $i 13; $i++) {
+ $monthNames[]=$wgContLang-getMonthName($i);
+
$monthNamesShort[]=$wgContLang-getMonthAbbreviation($i);
+ }
/pre
This does not conform to whitespace conventions. Also, this array building code
should be moved into the Language class so you can just call e.g.
code$wgContLang-getMonthNames()/code
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85366]: Revision status changed
User ^demon changed the status of MediaWiki.r85366. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85366#c0 Commit summary: Fix target of some class constants ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85402]: New comment added
User ^demon posted a comment on MediaWiki.r85402. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85402#c16008 Commit summary: Kill usage of global $title, non existent in core Comment: Obviously you didn't read where I said Don't backport to 1.17 because this is trivial, harmless, and may Break Something. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86113]: Revision status changed
User MaxSem changed the status of MediaWiki.r86113. Old Status: new New Status: fixme Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86113#c0 Commit summary: * added E_DEPRECATED into wfSupressWarnings merge into 1.17 if required PHP version will be 5.3+ ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86055]: Revision status changed
User ^demon changed the status of MediaWiki.r86055. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86055#c0 Commit summary: Added one @since annotation I had to check out ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86110]: Revision status changed
User ^demon changed the status of MediaWiki.r86110. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86110#c0 Commit summary: Update documentation ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86111]: Revision status changed
User ^demon changed the status of MediaWiki.r86111. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86111#c0 Commit summary: * Moved access layer stuff to /dataclasses * Moved /tests out of /maintenance ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86100]: New comment added, and revision status changed
User Simetrical changed the status of MediaWiki.r86100. Old Status: new New Status: fixme User Simetrical also posted a comment on MediaWiki.r86100. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86100#c16009 Commit summary: (bug 28540) revert r83544 - It really breaks things when using uca-default collation (As noticed on tw) Various functions (particuarly the getFirstCharacter ones) all expect to have the human readable sortkey. Passing them the binary sortkey results in the getFirstChar headers to be totally wrong. It also causes paging not to work since the sortkey gets double encoded. This issue probably wasn't noticed, since it wouldn't be visible on the uppercase collation as uppercasing the first letter won't affect the first character headings, nor does double uppercasing something matter. Also changed one of the variable names from $rawSortkey to $humanSortkey as it confused me (raw as in before turning to binary, or raw as in the real non-human readable sortkey) Comment: This is wrong for the reason I gave in the r83544 commit summary. I'd suggest that you use cl_sortkey if cl_collation is the empty string, otherwise use getCategorySortkey() as at present. Otherwise it will break if the categorylinks migration script hasn't yet run, or hasn't yet finished running. You're right that my commit was wrong, though. Apparently I misunderstood raw sortkey myself, although I wrote the code. I thought it meant possibly binary rather than unprocessed. I'd suggest that someone look through all the sortkey stuff and make sure it's clear in all cases whether you're dealing with 1) cl_sortkey_prefix, 2) the output of Title::getCategorySortkey(), or 3) cl_sortkey. Otherwise you'll probably see more confusion and bugs like this. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86041]: New comment added
User Bawolff posted a comment on MediaWiki.r86041. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86041#c16010 Commit summary: r86001, now with less scariness :P I took out the delete action and did purge instead, which is a much more self-contained action-with-a-form. Also implement a few changes suggested by Brion on IRC last night. Comment: I suppose in many ways redirecting (providing it redirects to the right place) does make sense. After all purging is the act of getting rid of the old version, which is quite separate from viewing. It could potentially cause confusion to users who expect to see the ?action=purge, but they'd get over it pretty quickly. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r73743]: New comment added
User Duplicatebug posted a comment on MediaWiki.r73743. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73743#c16011 Commit summary: Actually do r73742 Comment: Looks better after r85276 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Merging content from multiple wikis
On 29.03.2011 18:15, Daniel Friesen wrote: SphinxSearch also has a number of other disadvantages: - The 'did you mean' is only a spellcheck, it's not index based and not sensitive to your wiki's actual content so suggestions can be quite bad in some cases. They were so bad for me the feature was useless. - The interface for SphinxSearch seams to be out of date - The index cannot be updated live on-save, so there is delay between changing content and it getting into the index - Sphinx queries the sql directly so it's incompatible with compressed revs, external storage, and essentially any attempt at making storage of page text efficient in any way at all New version of Sphinx can update index on the fly, however I am not sure it's compatible with the extension. Another points are probably true, however compressed revs and external storage is probably not required for not so huge wikis it's being targeted for. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Status of 1.17 1.18
On Thu, Apr 14, 2011 at 9:17 AM, Mark A. Hershberger mhershber...@wikimedia.org wrote: But after a bit of discussion on IRC, I think we should try to get Tim's, Brion's and anyone else's opinion on what they think about the release schedule and code review. I say push out a release immediately. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Status of 1.17 1.18
On Fri, Apr 15, 2011 at 2:26 AM, Roan Kattouw roan.katt...@gmail.comwrote: 2011/4/15 Tim Starling tstarl...@wikimedia.org: My preference is for 2 to 3 major releases per year. We branched 1.17 in December and we're looking at doing a release in April. So a 4 month cycle would imply branching 1.18 in April and releasing in August. I don't think having 4 or 5 major releases per year would serve anyone particularly well. A slower release cadence means: I can get on board with having 3 releases per year, but I'll reiterate that 3 months, let alone 4, between branching and releasing is too long. I'd be happy with about two weeks: push 'beta' tarballs in the first week, 'release candidates' in the second week. In the meantime, we should be running 1.18 on live servers, with a maximum of a week lag from trunk, and preferably much less. Ongoing work on trunk should always be keeping stability in mind, and code review should concentrate on ensuring that code is being actively tested and used. I know we had some delays due to wanting to finish the security fixes, but I'm extremely concerned that trunk hasn't been being maintained this way since the initial 1.17 push. Unexercised code is dangerous code that will break when you least expect it; we need to get code into use fast, where it won't sit idle until we push it live with a thousand other things we've forgotten about. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Status of 1.17 1.18
2011/4/15 Brion Vibber br...@pobox.com: I'd be happy with about two weeks: push 'beta' tarballs in the first week, 'release candidates' in the second week. In the meantime, we should be running 1.18 on live servers, with a maximum of a week lag from trunk, and preferably much less. Ongoing work on trunk should always be keeping stability in mind, and code review should concentrate on ensuring that code is being actively tested and used. Amen to this, the rest of your post, and your previous post (release 1.17 ASAP). You're formulating my opinions better than I could; cheesy-sounding but true :P Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r86041]: New comment added
User Happy-melon posted a comment on MediaWiki.r86041. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86041#c16012 Commit summary: r86001, now with less scariness :P I took out the delete action and did purge instead, which is a much more self-contained action-with-a-form. Also implement a few changes suggested by Brion on IRC last night. Comment: I would hope that they'd quickly see, or at least subconsciously accept, the similarity in behaviour between action=purge, which redirects back to action=view, and actions like protect, edit, etc, which do the same thing (and have for ever). What does ''not'' make semantic sense is to be seeing the view of an article on an action which is not view. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86041]: New comment added
User Nikerabbit posted a comment on MediaWiki.r86041. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86041#c16013 Commit summary: r86001, now with less scariness :P I took out the delete action and did purge instead, which is a much more self-contained action-with-a-form. Also implement a few changes suggested by Brion on IRC last night. Comment: It could help if the redirection actually worked :/ ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85770]: New comment added
User Duplicatebug posted a comment on MediaWiki.r85770. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85770#c16014 Commit summary: * (bug 27712) add parent_id to list=deletedrevs Comment: You have to handle null values for that field. In my opinion it is nicer to have nothing, than parentid=0. Thanks. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86100]: New comment added, and revision status changed
User Bawolff changed the status of MediaWiki.r86100. Old Status: fixme New Status: new User Bawolff also posted a comment on MediaWiki.r86100. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86100#c16015 Commit summary: (bug 28540) revert r83544 - It really breaks things when using uca-default collation (As noticed on tw) Various functions (particuarly the getFirstCharacter ones) all expect to have the human readable sortkey. Passing them the binary sortkey results in the getFirstChar headers to be totally wrong. It also causes paging not to work since the sortkey gets double encoded. This issue probably wasn't noticed, since it wouldn't be visible on the uppercase collation as uppercasing the first letter won't affect the first character headings, nor does double uppercasing something matter. Also changed one of the variable names from $rawSortkey to $humanSortkey as it confused me (raw as in before turning to binary, or raw as in the real non-human readable sortkey) Comment: Sounds like a good plan. Did that in r86121. resetting revision to new ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81731]: Revision status changed
User ^demon changed the status of MediaWiki.r81731. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81731#c0 Commit summary: Remove $wgServer prepending from remote JS/CSS paths. It's not needed and breaks other-domain $wgStylePath / $wgExtensionAssetsPath settings ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85547]: Revision status changed
User ^demon changed the status of MediaWiki.r85547. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85547#c0 Commit summary: notes for r85546 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85377]: Revision status changed
User ^demon changed the status of MediaWiki.r85377. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85377#c0 Commit summary: Workaround for bug 28146: running out of memory during Unicode validation/normalization when uploading DjVu file with lots of embedded page text This provisional workaround runs a page at a time through UtfNormal::cleanUp() instead of running the entire file's dumped text at once. This avoids exploding memory too much during the preg_match_all() used to divide up ASCII and non-ASCII runs for validation, which is very wasteful for long texts in Latin languages with many mixed-in non-ASCII characters (like French and German text). Won't fix legit cases of huge texts, such as really long page text, which would still be subject to getting run through at web input time in a giant chunk. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85598]: Revision status changed
User ^demon changed the status of MediaWiki.r85598. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85598#c0 Commit summary: * (bug 28176) Review and enable CLDR extension Guard the PHP file inclusions against path traversal ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85583]: Revision status changed
User ^demon changed the status of MediaWiki.r85583. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85583#c0 Commit summary: * (bug 28444) Fix regression: edit-on-doubleclick retains revision id again Regression in 61071 caused by dropping $title-getLocalUrl($skin-getEditUrlOptions()) for the less informational $title-getEditUrl(), thus losing oldid view information. Switching back nicely resolves it. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84497]: Revision status changed
User ^demon changed the status of MediaWiki.r84497. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84497#c0 Commit summary: When switching from admin to non-admin account, make sure to set $this-db to null, otherwise MW will happily return the old handle, which means we end up in the old admin database, and thus create our 'mediawiki' schema in the postgres or template1 database (whoops!). There may be other similar cases in the code in which we are not clearing this-db before toggling the useAdmin attribute. Fixes bug 28171. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Status of 1.17 1.18
On 04/15/2011 12:07 PM, Brion Vibber wrote: Unexercised code is dangerous code that will break when you least expect it; we need to get code into use fast, where it won't sit idle until we push it live with a thousand other things we've forgotten about. Translate wiki deserves major props for running a real world wiki on trunk. Its hard to count all the bugs get caught that way. Maybe once the heterogeneous deployment situation gets figured out we could do something similar with a particular project... peace, --michael ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r84973]: Revision status changed
User ^demon changed the status of MediaWiki.r84973. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84973#c0 Commit summary: using jQuery hide() and show() instead of accessing the dom element directly from the jQuery object (either use jQuery or dont..). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85146]: Revision status changed
User ^demon changed the status of MediaWiki.r85146. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85146#c0 Commit summary: Reword this message per IRC cabbage ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85761]: Revision status changed
User ^demon changed the status of MediaWiki.r85761. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85761#c0 Commit summary: Remove double ; from r84971 Make explicit that the previous values of $wgAutoloadClasses are not preserved and make happy the 'unused global' detector. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85803]: Revision status changed
User ^demon changed the status of MediaWiki.r85803. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85803#c0 Commit summary: Bug 28478: database error in DatabaseSqlite::getFulltextSearchModule(). It was caused by a weird bug in SQLite: virtual table using a non-existent module still gets created somehow, and it is completely undeletable. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86074]: Revision status changed
User ^demon changed the status of MediaWiki.r86074. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86074#c0 Commit summary: Localisation updates for ToolserverI18N messages from translatewiki.net (2011-04-14 19:30:00 UTC) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86079]: Revision status changed
User ^demon changed the status of MediaWiki.r86079. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86079#c0 Commit summary: Followup r85885: Better error message for an insufficient pagesize in a DB2 database. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85727]: Revision status changed
User ^demon changed the status of MediaWiki.r85727. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85727#c0 Commit summary: Rebuild of Math messages previously in core. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85724]: Revision status changed
User ^demon changed the status of MediaWiki.r85724. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85724#c0 Commit summary: ...and remove the math-related messages from MessagesEn.php; follow-up to r85723 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85728]: Revision status changed
User ^demon changed the status of MediaWiki.r85728. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85728#c0 Commit summary: Follow-up r85724: update messages.inc and rebuild all language files. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85735]: Revision status changed
User ^demon changed the status of MediaWiki.r85735. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85735#c0 Commit summary: Followup to r85706 and friends: now that Math messages have been moved to extension, move out the settings list and constants. * MW_MATH_* constants are now defined in Math extension * Language::getMathNames() is removed * mathNames section in message files is removed * A hardcoded preference override in refreshLinks moved to MaintenanceRefreshLinksInit hook ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85723]: Revision status changed
User ^demon changed the status of MediaWiki.r85723. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85723#c0 Commit summary: Math extension: *coding style tweaks *documentation *check for MediaWiki environment in the main setup file *add extension credits *add i18n file (only English at the moment); messages from core MessagesEn.php This is a follow-up to Brion's r85706. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86065]: Revision status changed
User ^demon changed the status of MediaWiki.r86065. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86065#c0 Commit summary: Ensure $collationConds is defined on all paths ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81696]: Revision status changed
User ^demon changed the status of MediaWiki.r81696. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81696#c0 Commit summary: Back out trunk r70657. It's broken without the $wgAdaptiveMessageCache-related followups, which were reverted. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81833]: Revision status changed
User ^demon changed the status of MediaWiki.r81833. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81833#c0 Commit summary: Fixup fixme on r81030, which should actually have been a fixme on r81657 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81835]: Revision status changed
User ^demon changed the status of MediaWiki.r81835. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81835#c0 Commit summary: 1.17wm1: MFT r81833 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81834]: Revision status changed
User ^demon changed the status of MediaWiki.r81834. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81834#c0 Commit summary: MFT r81657, and fixing revision r81833 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81873]: Revision status changed
User ^demon changed the status of MediaWiki.r81873. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81873#c0 Commit summary: MFT: r81827, fixes total breakage of the installer ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r82730]: Revision status changed
User ^demon changed the status of MediaWiki.r82730. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82730#c0 Commit summary: MFT r82727, 82729 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r82961]: Revision status changed
User ^demon changed the status of MediaWiki.r82961. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82961#c0 Commit summary: Merge r82960 to REL1_17, fixing r82819 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r82819]: Revision status changed
User ^demon changed the status of MediaWiki.r82819. Old Status: ok New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82819#c0 Commit summary: MFT r82810, r82813, r82814, r82815, r82818 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r83932]: Revision status changed
User ^demon changed the status of MediaWiki.r83932. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83932#c0 Commit summary: 1.17wmf1: MFT r78990, r79844, r81548, r82022, r82193, r83061, r83067, r83583, r83610, r83716, r83764, r83787, r83813, r83866. Just copied ApiQueryUsers.php from trunk because the conflicts drove me crazy ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r83803]: Revision status changed
User ^demon changed the status of MediaWiki.r83803. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83803#c0 Commit summary: (follow-up r83716) fix parser test for the entities being decoded into numeric entities thing. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r83717]: Revision status changed
User ^demon changed the status of MediaWiki.r83717. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83717#c0 Commit summary: Backport r83716 Normalize named entities to numeric Didn't bother merging the parser tests, so those are only in trunk. Original commit message: We should never be outputting named entities other than the ones in XML, lt; gt; amp; quot;, because that will break well-formedness unless we have a DTD in the doctype, which we don't in HTML5 mode. I stuck with outputting numeric entities here instead of UTF-8 because some characters are hard to read in UTF-8 (e.g., nbsp;). Maybe it would be nicer if we decoded to UTF-8 except for whitespace and control characters, or something like that, but it's a detail. I'll backport to 1.17 and add RELEASE-NOTES there, which is why I added the line to HISTORY instead of RELEASE-NOTES. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r83755]: New comment added
User ^demon posted a comment on MediaWiki.r83755. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83755#c16016 Commit summary: Deprecate $wgSysopUserBans and $wgSysopRangeBans, both of which are pre-1.2, and totally antiquated. Can't think of any reason why a modern wiki might want to make blocks IP-only; syadmins can still disable rangeblocks by setting $wgBlockCIDRLimit to the maximum for each IP mode (32 for IP4, 128 for IP6). Comment: This has to do with bug 18807, yay :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r83757]: Revision status changed
User ^demon changed the status of MediaWiki.r83757. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83757#c0 Commit summary: Follow-up r83755: Message 'ipaddress' is unused now, in core and extensions ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r83776]: Revision status changed
User ^demon changed the status of MediaWiki.r83776. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83776#c0 Commit summary: Backport the deprecation of $wgSysopRangeBans and $wgSysopUserBans from r83755 to 1.17. The only functional change is to change the error message produced from setting $wgBlockCIDRLimit['IPv4'] = 32 from range too big to rangeblock disabled. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r83755]: Revision status changed
User ^demon changed the status of MediaWiki.r83755. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83755#c0 Commit summary: Deprecate $wgSysopUserBans and $wgSysopRangeBans, both of which are pre-1.2, and totally antiquated. Can't think of any reason why a modern wiki might want to make blocks IP-only; syadmins can still disable rangeblocks by setting $wgBlockCIDRLimit to the maximum for each IP mode (32 for IP4, 128 for IP6). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86125]: New comment added
User ^demon posted a comment on MediaWiki.r86125. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86125#c16017 Commit summary: Followup r83755: You removed them, you didn't deprecate them (there is a difference). If you're going to remove them, go the whole way rather than having people think they might still work. Comment: Well rephrase: they were deprecated in r83776 for the REL1_17 version. In 1.18 they were removed in r83776 and followups. REL-NOTES are already correct. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r82506]: Revision status changed
User Reedy changed the status of MediaWiki.r82506. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82506#c0 Commit summary: register PagesWithoutScans page in QueryPages ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84521]: Revision status changed
User ^demon changed the status of MediaWiki.r84521. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84521#c0 Commit summary: Backported r84388 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84122]: Revision status changed
User ^demon changed the status of MediaWiki.r84122. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84122#c0 Commit summary: spelling fixes and clarifying sentence about raw loading of resource loader modules ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85156]: Revision status changed
User ^demon changed the status of MediaWiki.r85156. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85156#c0 Commit summary: Localisation updates from translatewiki.net * Backport compatible translations to REL1_17 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86130]: New comment added
User Bawolff posted a comment on MediaWiki.r86130. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86130#c16018 Commit summary: (follow-up r69626) Make it so the intl normalizer_normalize function is not fed an invalid sequence in UtfNormal::cleanUp normalizer_normalize seems to return false if fed an invalid unicode sequence (Which is quite different from what our built in normalization functions do). So use quickIsNFC if it returns false. (Noticed when investigating bug 28541). Comment: Adding tags 1.17, 1.17wmf1. (which probably means I should not have touched the release notes, whoops) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Status of 1.17 1.18
Hoi, It makes sense for translatewiki.net to run on trunk. This way we are exposed to the latest messages and get as much localisation done before code actually hits production servers. Running another project just because it will run trunk only makes sense when it running trunk has added value. What you can do is adopt translatewiki.net as your barometer for code quality and help it run as smoothly as possible. Thanks, GerardM On 15 April 2011 19:36, Michael Dale md...@wikimedia.org wrote: On 04/15/2011 12:07 PM, Brion Vibber wrote: Unexercised code is dangerous code that will break when you least expect it; we need to get code into use fast, where it won't sit idle until we push it live with a thousand other things we've forgotten about. Translate wiki deserves major props for running a real world wiki on trunk. Its hard to count all the bugs get caught that way. Maybe once the heterogeneous deployment situation gets figured out we could do something similar with a particular project... peace, --michael ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85399]: Revision status changed
User ^demon changed the status of MediaWiki.r85399. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85399#c0 Commit summary: Follow-up r85354: back out part of r81524 which somehow got caught up in the merge and caused fatals on every page view. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85401]: Revision status changed
User ^demon changed the status of MediaWiki.r85401. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85401#c0 Commit summary: Tidy up a few unused/doubley declared globals ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85752]: Revision status changed
User ^demon changed the status of MediaWiki.r85752. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85752#c0 Commit summary: SQLite is picky about the position of AUTOINCREMENT in field definition, handle it when converting from MySQL syntax ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85753]: Revision status changed
User ^demon changed the status of MediaWiki.r85753. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85753#c0 Commit summary: 1.17: MFT r85752 (MySQL -- SQLite compatibility tweak) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86112]: Revision status changed
User ^demon changed the status of MediaWiki.r86112. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86112#c0 Commit summary: * updated tableName function changed addIdentifierQuotes, added isQuotedIdentifier and removeIdentifierQuotes * quoting objects in Oracle is poorly supported prior to 10g (it still has bugs in 10g) so i wish to avoid it for as long as possible * i've added /*Q*/ marker to avoid double-prefixing of table names * tableName quoted parameter is usable only in cases where you call it directly in functions where it might occur that tableName can get called twice it is unusable as the tableName gets prefixed twice Oracle documentation is generally crappy. They claim a lot of things but some of those claims depend on a gazillion of factors and in case of one of this factors being a bit off have no general solution. Object name quoting is one of such things and is general practice amongst oracle DBAs that if you write the code directly you can use them but if you write abstracted or embedded code it's best to stay away if you can. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85786]: Revision status changed
User ^demon changed the status of MediaWiki.r85786. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85786#c0 Commit summary: * fix as per brion's comment on r85669 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85791]: Revision status changed
User ^demon changed the status of MediaWiki.r85791. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85791#c0 Commit summary: Localisation updates from translatewiki.net * Backport compatible translations to REL1_17 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85871]: Revision status changed
User ^demon changed the status of MediaWiki.r85871. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85871#c0 Commit summary: Add new message key from r85844 to maintenance file ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
