[Wikitech-l] 1.18 Code Review and FIXME status
We're doing well on the road to 1.18. We went from ~370 un-reviewed revisions on last weekend to ~210 un-reviewed revisions today. We need to sustain this momentum to have 1.18 ready for release in time. One area that hasn't been getting enough attention, though, is FIXME'd revisions. On Monday, there were 95 FIXMEs and today that was only reduced to 86. We need that rate to really increase, so on Monday, I'll be contacting people with FIXME'd revisions and asking them to take action. If you don't have time, please let me, Robla, or the list know so that we can make sure that we have the code in a releasable state in time for release. (Information in this email was gleaned from the Revision Report: http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.18/Revision_report) Thanks, Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r92559]: New comment added
User "SPQRobin" posted a comment on MediaWiki.r92559. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92559#c20719 Commit summary: Major update of stable features from development code. * For non-existing info pages (Wx/xx[x] pages), add a welcome page (either missing, existing or closed wikis) * It automatically checks the database list if available (which is the case on WMF wikis), like SiteMatrix * Pages belonging to existing wikis are not editable and show a link to the existing wiki. You will be redirected automatically if URL &testwiki or your preference is set to that test wiki. * Show a logo per-project, and possibility to set it per-wiki (if URL &testwiki or your preference is set to that test wiki) This is developed against 1.17wmf1 so everything should work on Incubator itself. Comment: $wmincClosedWikis set to false by default in r94434. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94422]: New comment added
User "Catrope" posted a comment on MediaWiki.r94422. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/94422#c20718 Commit summary: Add a RELEASE-NOTES note about protocol-relative URLs to the 1.18 RELEASE-NOTES. Support for protocol-relative URLs is almost-there-but-not-quite at this point, so this is a little bit preliminary, but we will deploy this on WMF soon and merge all fixes to 1.18, so I figured it's better to put this in now before I forget. Comment: Thanks. I've beefed that section up a bit. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94431]: New comment added
User "Nikerabbit" posted a comment on MediaWiki.r94431. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94431#c20717 Commit summary: 1.0.1 RC Comment: berepresented ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94350]: New comment added
User "Catrope" posted a comment on MediaWiki.r94350. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/94350#c20716 Commit summary: Fix r91886 thanks to johnduhart: check if it is an IP *before* stripping subpages, otherwise IP range blocking does not work Comment: ...and now I can't reproduce the test failure on trunk. CruiseControl has also been reproducing it intermittently. This is really weird. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94422]: New comment added
User "Catrope" posted a comment on MediaWiki.r94422. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/94422#c20715 Commit summary: Add a RELEASE-NOTES note about protocol-relative URLs to the 1.18 RELEASE-NOTES. Support for protocol-relative URLs is almost-there-but-not-quite at this point, so this is a little bit preliminary, but we will deploy this on WMF soon and merge all fixes to 1.18, so I figured it's better to put this in now before I forget. Comment: Already done, see 1.18 merge queue (which grew from 30 to 45 as I did so). I have to keep track of them anyway because I have deployed them (and am deploying more of them later) to the cluster ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94422]: New comment added
User "MarkAHershberger" posted a comment on MediaWiki.r94422. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94422#c20714 Commit summary: Add a RELEASE-NOTES note about protocol-relative URLs to the 1.18 RELEASE-NOTES. Support for protocol-relative URLs is almost-there-but-not-quite at this point, so this is a little bit preliminary, but we will deploy this on WMF soon and merge all fixes to 1.18, so I figured it's better to put this in now before I forget. Comment: make sure you tag the appropriate revisions for backporting. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94422]: New comment added
User "Hashar" posted a comment on MediaWiki.r94422. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94422#c20713 Commit summary: Add a RELEASE-NOTES note about protocol-relative URLs to the 1.18 RELEASE-NOTES. Support for protocol-relative URLs is almost-there-but-not-quite at this point, so this is a little bit preliminary, but we will deploy this on WMF soon and merge all fixes to 1.18, so I figured it's better to put this in now before I forget. Comment: I have edited the mw.org release note at http://www.mediawiki.org/wiki/MediaWiki_1.18#Protocol_relative_URLs :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94422]: New comment added, and revision status changed
User "Hashar" changed the status of MediaWiki.r94422. Old Status: new New Status: ok User "Hashar" also posted a comment on MediaWiki.r94422. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94422#c20712 Commit summary: Add a RELEASE-NOTES note about protocol-relative URLs to the 1.18 RELEASE-NOTES. Support for protocol-relative URLs is almost-there-but-not-quite at this point, so this is a little bit preliminary, but we will deploy this on WMF soon and merge all fixes to 1.18, so I figured it's better to put this in now before I forget. Comment: Good to know that relative URLs will be part of 1.18 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94350]: New comment added
User "Catrope" posted a comment on MediaWiki.r94350. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/94350#c20711 Commit summary: Fix r91886 thanks to johnduhart: check if it is an IP *before* stripping subpages, otherwise IP range blocking does not work Comment: Yes, you'd need new test cases to cover the bug fix. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94350]: New comment added
User "^demon" posted a comment on MediaWiki.r94350. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94350#c20710 Commit summary: Fix r91886 thanks to johnduhart: check if it is an IP *before* stripping subpages, otherwise IP range blocking does not work Comment: This probably means we need additional test cases as well. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94351]: Revision status changed
User "Catrope" changed the status of MediaWiki.r94351. Old Status: new New Status: reverted Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/94351#c0 Commit summary: merge r94350 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94420]: Revision status changed
User "^demon" changed the status of MediaWiki.r94420. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94420#c0 Commit summary: Revert r94351, which merged r94350 from trunk to 1.18: code was unreviewed and breaks a unit test. I'll tag r94350 for merging, it'll be merged once it's been fixed and reviewed. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94350]: New comment added, and revision status changed
User "Catrope" changed the status of MediaWiki.r94350.
Old Status: new
New Status: fixme
User "Catrope" also posted a comment on MediaWiki.r94350.
Full URL:
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/94350#c20709
Commit summary:
Fix r91886 thanks to johnduhart: check if it is an IP *before* stripping
subpages, otherwise IP range blocking does not work
Comment:
Causes a test failure:
Error:
BlockTest::testInitializerFunctionsReturnCorrectBlock
Argument 1 passed to Block::equals() must be an instance of Block, null given,
called in
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/includes/BlockTest.php
on line 68 and defined
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/includes/Block.php:136
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/includes/BlockTest.php:68
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/MediaWikiTestCase.php:60
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/MediaWikiPHPUnitCommand.php:20
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/phpunit.php:60
The backtrace is a bit of a red herring. The unit test triggering the error is
this:
/**
* CheckUser since being changed to use Block::newFromTarget started
failing
* because the new function didn't accept empty strings like
Block::load()
* had. Regression bug 29116.
*
* @dataProvider dataBug29116
*/
function testBug29116NewFromTargetWithEmptyIp( $vagueTarget ) {
$block = Block::newFromTarget('UTBlockee', $vagueTarget);
$this->assertTrue( $this->block->equals( $block ),
"newFromTarget() returns the same block as the one that was made when given
empty vagueTarget param " . var_export( $vagueTarget, true ) );
}
So what happens is that newFromTarget() returns null (which is the
real issue), and equals() barfs on it (which is what causes the
error).
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94373]: New comment added
User "Dantman" posted a comment on MediaWiki.r94373. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/94373#c20708 Commit summary: Improve the ability for extensions to participate in how MediaWiki handles url paths: - Allow extensions to hook into WebRequest::getPathInfo and add to or alter the way titles are extracted from paths - Add a $variant argument to the GetLocalURL hook; It's always had $query, but never had $variant. As a result extensions using GetLocalURL never new if getLocalURL and have the possibility of trying to change the url in cases where they shouldn't and as a result breaking links on wiki with language variants. - Add GetLocalURL::Internal hook for non-interwiki links. These kinds of links internally use a ugly hack for action=render and an extension using GetLocalURL can be buggy in render mode if they don't re-implement the same ugly hack that MW does. This ::Internal hook runs before the hack does so extension authors don't need to be exposed to our ugly hacky code. - Add GetLocalURL::Article hook specifically for url tweaks to pretty urls (ie: Only when we would apply $wgArticlePath); This hook avoids the need for extensions that only want to tweak pretty url output. This hook avoids the need to make a bunch of tests for things like !$title->isExternal(), $query == '', and $variant === false which getLocalURL does and could potentially change in the future making wider GetLocalURL hooks change in function requiring extension updates. Comment: The & is really only there for consistency. It practically has no meaning, but since GetLocalURL already has it there, I just kept the pattern instead of messing with things. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94373]: New comment added
User "Nikerabbit" posted a comment on MediaWiki.r94373. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94373#c20707 Commit summary: Improve the ability for extensions to participate in how MediaWiki handles url paths: - Allow extensions to hook into WebRequest::getPathInfo and add to or alter the way titles are extracted from paths - Add a $variant argument to the GetLocalURL hook; It's always had $query, but never had $variant. As a result extensions using GetLocalURL never new if getLocalURL and have the possibility of trying to change the url in cases where they shouldn't and as a result breaking links on wiki with language variants. - Add GetLocalURL::Internal hook for non-interwiki links. These kinds of links internally use a ugly hack for action=render and an extension using GetLocalURL can be buggy in render mode if they don't re-implement the same ugly hack that MW does. This ::Internal hook runs before the hack does so extension authors don't need to be exposed to our ugly hacky code. - Add GetLocalURL::Article hook specifically for url tweaks to pretty urls (ie: Only when we would apply $wgArticlePath); This hook avoids the need for extensions that only want to tweak pretty url output. This hook avoids the need to make a bunch of tests for things like !$title->isExternal(), $query == '', and $variant === false which getLocalURL does and could potentially change in the future making wider GetLocalURL hooks change in function requiring extension updates. Comment: Yay, I think I can now simplify my hook which disables pretty paths if there is ? & or // in the url. Documentation for GetLocalURL::Internal doesn't mention '''&''' for $this... is it needed at all? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94415]: Revision status changed
User "Reedy" changed the status of MediaWiki.r94415. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94415#c0 Commit summary: svn:eol-style native ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Mark your calendar: MediaWiki hackathon, New Orleans, 14-16 Oct.
On 12.08.2011 16:36, Roan Kattouw wrote: > I second this notion, meeting up with local Wikimedians in some way, > maybe even inviting them to hang around the venue even if they're not > coders, sounds like a great idea. > > Roan Kattouw (Catrope) >From my experience, it works pretty well to invite local wiki[pm]edians to any social events / parties around the hackathon. An open Q/A session at some point during the hackathon, perhaps at the end of the first day, or last thing on the last day (before some party) could also work. But it may be that not many people would show up for that. Depends very much I guess. -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r94410]: New comment added
User "^demon" posted a comment on MediaWiki.r94410. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94410#c20706 Commit summary: svn ignore + README file Comment: Tim already had an .svnignore on r94402, I was about to move that to a svn:ignore and drop the file. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] question about common information templates
Is there any plan according to supersede the old template system with built-in software support in core or in extension, at least partially? I mean there are several common templates, that should be designed once and professionally, and used on all Wikipedias: like amboxes, infoboxes, navboxes, coordinate templates, portal templates, sister project templates, and so on. And I don't mean a „template-commons” with unchanged template syntax, but real software support. Users became more and more „perverse” about creating more complicated and resource-hungry templates, what only a few editor can modify and understand correctly, because their complexity. The current practise is far from ideal, these templates I mentioned above should look uniform, and be informational. Currently they are target to bikeshed operations: on the hungarian Wikipedia, there was even a voting about the font size of the infoboxes. Wikipedia is not a coloring book, and not about constant redesigning of important parts of the articles. As we do not change the default skin in every half a year, we should not allow to change the look of standard informational elements, at least not in that amateur way („my favourite color/font is better than yours!”). And I not even mentioned, that high percentage of the current templates are full of not valid html code, because the average user do not understand (and should not have to understand) html/html5/css/advanced parser functions. So, is there any plan or ongoing debate/developement about this? * * Farewell, *Glanthor* ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r94029]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r94029. Old Status: ok New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94029#c0 Commit summary: Warn user if mod_security is present ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94408]: Revision status changed
User "^demon" changed the status of MediaWiki.r94408. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94408#c0 Commit summary: Rm debugging hack from r94029. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94406]: Revision status changed
User "MaxSem" changed the status of MediaWiki.r94406. Old Status: new New Status: reverted Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94406#c0 Commit summary: Purposefully break two tests so I can see how Jenkins reacts to it. Will rv immediately ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94407]: Revision status changed
User "MaxSem" changed the status of MediaWiki.r94407. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94407#c0 Commit summary: rvv (r94406) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94171]: New comment added, and revision status changed
User "^demon" changed the status of MediaWiki.r94171. Old Status: new New Status: fixme User "^demon" also posted a comment on MediaWiki.r94171. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94171#c20705 Commit summary: (bug 30219) NoLocalSettings.php broken on Windows servers. Per Tim on r70711, can't use pathinfo() on url's since the slashes don't match. Comment: Grrr insufficient fix. Works on ugly urls, semi-pretty urls (using pathinfo), and rewritten urls. Does ''not'' work with Alias directives. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91402]: New comment added
User "Tim Starling" posted a comment on MediaWiki.r91402. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91402#c20704 Commit summary: Allow SqlBagOStuff data to be split over many tables, to avoid lock contention performance issues on servers with a high write load. See http://bugs.mysql.com/bug.php?id=61735 and http://bugs.mysql.com/bug.php?id=61736 . Comment: Maybe, but it's pretty likely nobody will ever run it. You would have to have a write rate similar to the whole of Wikimedia put together for this sharding option to make a performance difference. And hopefully it will be fixed in the next major version of MySQL, so it'll only be necessary for a few years. Also, the chances that someone will have such a large wiki running on a DBMS other than MySQL and that that DBMS will happen to have the same bug requiring the same hackish workaround seem rather slim to me. That's another reason why I'm not too concerned about the MySQL-specific code here. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87099]: Revision status changed
User "Tim Starling" changed the status of MediaWiki.r87099. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87099#c0 Commit summary: Provisional fix for Bug #28631 to remove artifacts from GIF. This seems better in my (very) limited testing than leaving it in, but I'd like to get more tests. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r93234]: Revision status changed
User "Catrope" changed the status of MediaWiki.r93234. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/93234#c0 Commit summary: Implement an accessor for User->mBlock. Doing this separately as it would be nice to backport this to 1.18 for the purposes of updating extensions for 1.19. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91402]: New comment added
User "Catrope" posted a comment on MediaWiki.r91402. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91402#c20703 Commit summary: Allow SqlBagOStuff data to be split over many tables, to avoid lock contention performance issues on servers with a high write load. See http://bugs.mysql.com/bug.php?id=61735 and http://bugs.mysql.com/bug.php?id=61736 . Comment: Lol, I didn't notice that it was for eval.php only. Maybe it should be a maintenance script? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r93711]: Revision status changed
User "Catrope" changed the status of MediaWiki.r93711. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/93711#c0 Commit summary: * (bug 30178) Narayam input manager: switch 'ta' as default before 'ta99' for Tamil Using explicit dependency order in addition to reordering the entries. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91402]: New comment added
User "Tim Starling" posted a comment on MediaWiki.r91402. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91402#c20702 Commit summary: Allow SqlBagOStuff data to be split over many tables, to avoid lock contention performance issues on servers with a high write load. See http://bugs.mysql.com/bug.php?id=61735 and http://bugs.mysql.com/bug.php?id=61736 . Comment: Max's comment is correct. Note that the code in question is not called from anywhere. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91402]: New comment added
User "Catrope" posted a comment on MediaWiki.r91402. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91402#c20701 Commit summary: Allow SqlBagOStuff data to be split over many tables, to avoid lock contention performance issues on servers with a high write load. See http://bugs.mysql.com/bug.php?id=61735 and http://bugs.mysql.com/bug.php?id=61736 . Comment: Untagging 1.17wmf1, already merged and deployed. Tim, could you respond to MaxSem's comment? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94353]: New comment added
User "Nikerabbit" posted a comment on MediaWiki.r94353. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/94353#c20700 Commit summary: Followup r94349; Interwiki::getURL used `$title != null` to test if the $title arg was passed and should be substituted. However `"" == null`, so as a result switching to using the argument broke [[mw:]] style interwiki links without an article title. Update the Interwiki::getURL code to use isset(), and update the comment to tell pre-1.19 supporting extensions to do the entire urlencoding and $1 substitution on their own since Interwiki::getURL was essentially buggy and broken before now. Comment: I prefer !== null, but like said they are equivalent. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94353]: New comment added
User "Catrope" posted a comment on MediaWiki.r94353. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/94353#c20699 Commit summary: Followup r94349; Interwiki::getURL used `$title != null` to test if the $title arg was passed and should be substituted. However `"" == null`, so as a result switching to using the argument broke [[mw:]] style interwiki links without an article title. Update the Interwiki::getURL code to use isset(), and update the comment to tell pre-1.19 supporting extensions to do the entire urlencoding and $1 substitution on their own since Interwiki::getURL was essentially buggy and broken before now. Comment: I don't care much between is_null() and === null, they're equivalent. What I do care about is not using isset() for this, because it masks any mistakes you might make, such as variable name typos. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94353]: New comment added
User "Dantman" posted a comment on MediaWiki.r94353. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/94353#c20698 Commit summary: Followup r94349; Interwiki::getURL used `$title != null` to test if the $title arg was passed and should be substituted. However `"" == null`, so as a result switching to using the argument broke [[mw:]] style interwiki links without an article title. Update the Interwiki::getURL code to use isset(), and update the comment to tell pre-1.19 supporting extensions to do the entire urlencoding and $1 substitution on their own since Interwiki::getURL was essentially buggy and broken before now. Comment: Interesting... think we should push for the practice of using is_null()/!is_null() instead of isset or !== null? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94353]: New comment added
User "Nikerabbit" posted a comment on MediaWiki.r94353. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/94353#c20697 Commit summary: Followup r94349; Interwiki::getURL used `$title != null` to test if the $title arg was passed and should be substituted. However `"" == null`, so as a result switching to using the argument broke [[mw:]] style interwiki links without an article title. Update the Interwiki::getURL code to use isset(), and update the comment to tell pre-1.19 supporting extensions to do the entire urlencoding and $1 substitution on their own since Interwiki::getURL was essentially buggy and broken before now. Comment: Use is_null() then. Using isset() could easily make more bugs when the variable is renamed only partially. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94346]: Revision status changed
User "Hashar" changed the status of MediaWiki.r94346. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94346#c0 Commit summary: (bug 30236) Links like [[//example.com Link text]] were parsed as an internal link rather than an external link surrounded by brackets, like [[http://example.com Link text]]. Was caused by another pointless \b directly preceding wfUrlProtocols() in a regex. Also add a parser test for the [[http://example.com Link text]] case (the existing test only covered [[http://example.com]]) and add protocol-relative counterparts for both tests. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94354]: Revision status changed
User "Hashar" changed the status of MediaWiki.r94354. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94354#c0 Commit summary: Follow-up r94325: Fix name in module() as well, otherwise TestSwarm chokes ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94356]: Revision status changed
User "Hashar" changed the status of MediaWiki.r94356. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94356#c0 Commit summary: added doc ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94384]: Revision status changed
User "Hashar" changed the status of MediaWiki.r94384. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94384#c0 Commit summary: Update the Html5 void elements and boolean attributes, in accordance with the latest draft. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94358]: Revision status changed
User "Hashar" changed the status of MediaWiki.r94358. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94358#c0 Commit summary: Renaming qunit test files to end in ".test.js" (finally!) * There shouldn't be two files with the same name in core, especially not the module and the test suite. Previously postponed due to compatibility with our TestSwarm script, that has been fixed now. * Had to modify the files in the same commit since the module name is referenced inside the test suite in the module() call, which is the hint for QUnit when filtering is done through the ?filter= parameter. * As has been added to the conventions, there must be only one module() call per test suite file and it MUST match "filename without .test.js". Otherwise the module will not be submitted to TestSwarm (which glob()'s at the /suites/ directory and extracts test-suite-module-names from the filenames). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94359]: Revision status changed
User "Hashar" changed the status of MediaWiki.r94359. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94359#c0 Commit summary: Update our TestSwarm's check out script for r94358. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90849]: New comment added
User "Hashar" posted a comment on MediaWiki.r90849. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90849#c20696 Commit summary: Apply rgcjones' patch for Bug#29533: Whe placing an external link in the sidebar, $wgExternalLinkTarget is ignored. Also enables applying of $wgNoFollowLinks in the sidebar. Comment: That patch introduces code duplication :( The part that check for $wgNoFollowLinks is copy/pasted from Parser::getExternalLinkAttribs(). Although altered to not look at the Title namespace, probably because we do not have a valid Title object in the context of the sidebar. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] [Foundation-l] We need to make it easy to fork and leave
Yes, that tool looks similar to the idea I wrote. Other approaches may be possible too. 2011/8/13 John Vandenberg > On Sat, Aug 13, 2011 at 4:53 AM, emijrp wrote: > > Man, Gerard is thinking about new methods to fork (in an easy way) single > > articles, sets of articles or complete wikipedias, and people reply about > > setting up servers/mediawiki/importing_databases and other geeky weekend > > parties. That is why there is no successful forks. Forking Wikipedia is > > _hard_. > > > > People need a button to create a branch of an article or sets of > articles, > > and be allowed to re-write and work in the way they want. Of course, the > > resulting articles can't be saved/showed close to the Wikipedia articles, > > but in a new plataform. It would be an interesting experiment. > > Something like this.. ? > > http://wikimedia.org.au/wiki/Proposal:PersonalWikiTool > > -- > John Vandenberg > > ___ > foundation-l mailing list > foundatio...@lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r82610]: New comment added
User "Umherirrender" posted a comment on MediaWiki.r82610. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82610#c20695 Commit summary: * random redirect-related fixes: ** automatically add redirect=no to all links on the redirect page in Article::viewRedirect. ** properly check if redirects are enabled if $wgMaxRedirects < 1 (moved check from Title::newFromRedirectArray to Title::newFromRedirectInternal). Comment: Also the first link (handled outside of the loop) should have "redirect=no". ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] [Foundation-l] We need to make it easy to fork and leave
On Sat, Aug 13, 2011 at 4:53 AM, emijrp wrote: > Man, Gerard is thinking about new methods to fork (in an easy way) single > articles, sets of articles or complete wikipedias, and people reply about > setting up servers/mediawiki/importing_databases and other geeky weekend > parties. That is why there is no successful forks. Forking Wikipedia is > _hard_. > > People need a button to create a branch of an article or sets of articles, > and be allowed to re-write and work in the way they want. Of course, the > resulting articles can't be saved/showed close to the Wikipedia articles, > but in a new plataform. It would be an interesting experiment. Something like this.. ? http://wikimedia.org.au/wiki/Proposal:PersonalWikiTool -- John Vandenberg ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r94353]: New comment added
User "Dantman" posted a comment on MediaWiki.r94353. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/94353#c20694 Commit summary: Followup r94349; Interwiki::getURL used `$title != null` to test if the $title arg was passed and should be substituted. However `"" == null`, so as a result switching to using the argument broke [[mw:]] style interwiki links without an article title. Update the Interwiki::getURL code to use isset(), and update the comment to tell pre-1.19 supporting extensions to do the entire urlencoding and $1 substitution on their own since Interwiki::getURL was essentially buggy and broken before now. Comment: I wasn't aware that we used !== null in core. Could have sworn my practice of isset'ing optional args came from MediaWiki. !== null also sorta feels like a practice that could easily make more != null mistakes pop up and cause more bugs. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94353]: New comment added
User "Nikerabbit" posted a comment on MediaWiki.r94353. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94353#c20693 Commit summary: Followup r94349; Interwiki::getURL used `$title != null` to test if the $title arg was passed and should be substituted. However `"" == null`, so as a result switching to using the argument broke [[mw:]] style interwiki links without an article title. Update the Interwiki::getURL code to use isset(), and update the comment to tell pre-1.19 supporting extensions to do the entire urlencoding and $1 substitution on their own since Interwiki::getURL was essentially buggy and broken before now. Comment: What is wrong with !== null? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94289]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r94289. Old Status: fixme New Status: new Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94289#c0 Commit summary: * Added rev_sha1 and ar_sha1 columns to revision/archive tables (useful for bug 25312) * Created a script to populate these fields (doesn't handle archive rows without ar_rev_id set though) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r94370]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r94370.
Old Status: fixme
New Status: new
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94370#c0
Commit summary:
* Added LoggedUpdateMaintenance subclass
* Moved PopulateRevisionLength/PopulateRevisionSha1 scripts to
$postDatabaseUpdateMaintenance
* Fixed bogus "{$prefix}_sha1 != ''" comparison (r94362)
* Removed unneeded NOT NULL check (speeds up script a bit) from
populateRevisionSha1 script
* Various code cleanups
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
