[Wikitech-l] Welcoming Ian Baker
Hi All, Please join me in welcoming Ian Baker as Software Developer in the Features Engineering team. Ian's been a software developer for about 15 years. He's worked on projects like the first open-source web framework, a billing system for a regional ISP, a custom video transcoding system, and a sensor-based flamethrower controller. At Wikimedia Foundation, he hopes to code some awesome features, help find new ways for people to share and connect information, help improve the overall Mediawiki user experience, and advance the codebase towards present-day software development practices. Specific interests include data model design, database query optimization, regular expressions, user interfaces, human computer interaction and online communities. Ian has been building large-scale installation art since 2005, and has taught flame effects, fire performance, and fire safety classes at The Crucible and elsewhere since 2006. Ian is a founding member of the art collective Ardent Heavy Industries, including its fire art wing, Interpretive Arson. In other lifetimes, he’s worked as a broadcast engineer, welder, machinist, fire performer, drug educator, EMT, and photographer. And he also enjoys flower arrangement and aerial acrobatics. Wow - that’s a lot of cool interests :-) Feel free to say hello to Ian online or in person at WMF Engineering in San Francisco. Welcome Ian! -- Alolita Sharma Features Engineering Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91347]: New comment added
User "Schnark" posted a comment on MediaWiki.r91347.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91347#c19304
Commit summary:
Correct for in loops on arrays.
Reported in bug 29106. Patch by Michael M.
Comment:
Somehow there slipped some mistake in:
Line 110 should be
for ( i = 0; i < data.characters.length; i++ ) {
The i < and the s are missing.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Welcoming Ian Baker
On Thu, Jul 7, 2011 at 5:27 PM, Alolita Sharma wrote: > ...snip > engineer, welder, machinist, fire performer, drug educator, EMT, and > photographer. And he also enjoys flower arrangement and aerial > acrobatics. Wow - that’s a lot of cool interests :-) Hello and welcome Fire Performer? Aerial Acrobatics? that could make for some interesting wiki meetups and hack-a-thons ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91615]: New comment added
User "Nikerabbit" posted a comment on MediaWiki.r91615. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91615#c19305 Commit summary: * (bug 29481) Add German namespace names to LQT Comment: Just one tab is enough. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Apache configuration in mw1.17
Hi,
in release notes of mw 1.16.4 the following was suggested:
It is necessary to upgrade MediaWiki to avoid an XSS vulnerability for
Internet Explorer clients, version 6 and earlier. Also, if you used
the Apache configuration I suggested in the previous release
announcement, you should update it to:
RewriteEngine On
RewriteCond %{QUERY_STRING} \.[a-z0-9]{1,4}(#|\?|$) [nocase]
RewriteRule . - [forbidden]
Is this still suggested in the latest version? I have several problems with
file upload, when the option is enabled...
Best regards,
Johannes Weberhofer
--
Johannes Weberhofer
Weberhofer GmbH, Austria, Vienna
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91618]: New comment added
User "Hashar" posted a comment on MediaWiki.r91618. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91618#c19306 Commit summary: Replace bullet-icon.png with an 8-bit version (became 24-bit due to r78011 which removed the color palette) * Fixes (bug 19514) Unordered list list-style-image should be IE6-compatible (8-bit) Comment: Do we still have the color palette for the other icons? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91569]: Revision status changed
User "Hashar" changed the status of MediaWiki.r91569. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91569#c0 Commit summary: Declared some member fields ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91608]: New comment added
User "Bryan" posted a comment on MediaWiki.r91608. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91608#c19307 Commit summary: * (bug 28626) Validate JavaScript files and pages loaded via ResourceLoader before minification, protecting separate modules from interference This is possibly not perfect but seems to serve for a start; follows up on r91591 that adds JSMin+ to use it in some unit tests. May want to adjust some related bits. - $wgResourceLoaderValidateJs on by default (can be disabled) - when loading a JS file through ResourceLoaderFileModule or ResourceLoaderWikiModule, parse it using JSMinPlus's JSParser class. If the parser throws an exception, the JS code of the offending file will be replaced by a JS exception throw listing the file or page name, line number (in original form), and description of the error from the parser. - parsing results are cached based on md5 of content to avoid re-parsing identical text - for JS pages loaded via direct load.php request, the parse error is thrown and visible in the JS console/error log Issues: - the primary use case for this is when a single load.php request implements multiple modules via mw.loader.implement() -- the loader catches the exception and skips on to the next module (good) but doesn't re-throw the exception for the JS console. It does log to console if present, but it'll only show up as a regular debug message, not an error. This can suppress visibility of errors in a module that's loaded together with other modules (such as a gadget). - have not done performance testing on the JSParser - have not done thorough unit testing with the JSParser Comment: You should add the file name in the JavaScript error thrown. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91642]: New comment added
User "^demon" posted a comment on MediaWiki.r91642. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91642#c19308 Commit summary: Bug #29755: Apply patch from Vitaliy Filippov so that MW's HTTP client respects no_proxy env setting Comment: No tests? :( ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91641]: Revision status changed
User "^demon" changed the status of MediaWiki.r91641. Old Status: new New Status: reverted Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91641#c0 Commit summary: update script to check for truncated bz2s, to conform with exit code from updated program ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91643]: Revision status changed
User "^demon" changed the status of MediaWiki.r91643. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91643#c0 Commit summary: grrr, brain death syndrome strikes again, reverting 91641 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91642]: New comment added, and revision status changed
User "Bryan" changed the status of MediaWiki.r91642. Old Status: new New Status: fixme User "Bryan" also posted a comment on MediaWiki.r91642. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91642#c19309 Commit summary: Bug #29755: Apply patch from Vitaliy Filippov so that MW's HTTP client respects no_proxy env setting Comment: * Error suppression operator. Should never be used in new code. * Variable names do not match MediaWiki code conventions. Use $lowerCamelCase. * The absence of code comments, makes it almost impossible to review this. The regexes suggest that you are looking to IPv4 IP addresses. You should use the functions in the IP class for this, and also make this working with IPv6. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] [Selenium] IDE test for regressing bug https://bugzilla.wikimedia.org/show_bug.cgi?id=29310
Michelle: Thanks for the test & test suite! Just wanted to update you that it seems like fewer and fewer MediaWiki developers are interested in Selenium tests, and many are moving to other tools for automatic testing: http://www.mediawiki.org/wiki/Requests_for_comment/Unit_testing http://www.mediawiki.org/wiki/Test_framework_deployment#Status:_Permanent_hiatus http://www.mediawiki.org/wiki/Selenium_Framework#Selenium.27s_uses_.26_flaws Would you be interested in writing test suites or tests for some of these other tools? Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation On Tue, Jul 5, 2011 at 11:02 PM, Michelle Knight wrote: > Hi Benedikt and Marcus, > > I had some time and was reading about current issues around MediaWiki. I > saw > an issue about tab names - Bug 29310 Namespace tab doesn't handle fallback > the same way as core (breaks nstab) - and created a Selenium regression > test > to verify when it is fixed. It is called > javascript-unit-testing-checking-tabs-and-content. It verifies that the tab > names are correct. I also created a test suite - test-suite-check-tabs. The > suite includes a test to check the tabs on the main media wiki site (a test > that passes) and the test - > javscript-unit-testing-checking-tabs-and-content. Would you provided > feedback as to how useful the tests and how to improve them? > > Michelle Knight > > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91645]: New comment added, and revision status changed
User "Nikerabbit" changed the status of MediaWiki.r91645. Old Status: new New Status: ok User "Nikerabbit" also posted a comment on MediaWiki.r91645. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91645#c19310 Commit summary: Add several license messages per User:Pikne on translatewiki.net Comment: Looks good to me. Linking directly to the thread https://translatewiki.net/wiki/Thread:Translating_talk:MediaWiki/New_license_texts can be helpful. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Do we need Selenium for anything anymore? (was: [Selenium] IDE test for regressing bug)
On Thu, Jul 7, 2011 at 11:23 AM, Sumana Harihareswara wrote: > Thanks for the test & test suite! Just wanted to update you that it seems > like fewer and fewer MediaWiki developers are interested in Selenium tests, > and many are moving to other tools for automatic testing: > That being said: is there any reason to leave the Selenium support in core anymore? -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91646]: New comment added
User "^demon" posted a comment on MediaWiki.r91646. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91646#c19311 Commit summary: Rephrasing msg clearyourcache per Bug 27550 : Adding Chrome, moving up IE, making it a bulltetd list. Thanks Amir E. Aharoni Comment: Nobody calls it a Macintosh anymore... ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91639]: Revision status changed
User "Reedy" changed the status of MediaWiki.r91639. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91639#c0 Commit summary: svn:eol-style native ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91642]: New comment added
User "Hashar" posted a comment on MediaWiki.r91642. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91642#c19312 Commit summary: Bug #29755: Apply patch from Vitaliy Filippov so that MW's HTTP client respects no_proxy env setting Comment: I believe mark just applied the patch to get the bug closed. Lets just rewrite the above code :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Welcoming Ian Baker
On Thu, Jul 7, 2011 at 1:11 AM, K. Peachey wrote: > On Thu, Jul 7, 2011 at 5:27 PM, Alolita Sharma wrote: >> ...snip >> engineer, welder, machinist, fire performer, drug educator, EMT, and >> photographer. And he also enjoys flower arrangement and aerial >> acrobatics. Wow - that’s a lot of cool interests :-) > Hello and welcome > > Fire Performer? Aerial Acrobatics? that could make for some > interesting wiki meetups and hack-a-thons Especially since we have a couple more aerialists/performers already here :) Welcome Ian! --tomasz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91642]: New comment added
User "MarkAHershberger" posted a comment on MediaWiki.r91642. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91642#c19313 Commit summary: Bug #29755: Apply patch from Vitaliy Filippov so that MW's HTTP client respects no_proxy env setting Comment: You should've seen the patch I didn't submit! Good points, though. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91642]: New comment added
User "^demon" posted a comment on MediaWiki.r91642. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91642#c19314 Commit summary: Bug #29755: Apply patch from Vitaliy Filippov so that MW's HTTP client respects no_proxy env setting Comment: Well if we're just going to start blindly applying patches I've got 351 bugs in core we can go ahead and resolve ;-) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91642]: New comment added
User "Nikerabbit" posted a comment on MediaWiki.r91642. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91642#c19315 Commit summary: Bug #29755: Apply patch from Vitaliy Filippov so that MW's HTTP client respects no_proxy env setting Comment: Seems to get better review this way :o ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Welcoming Ian Baker
Welcome, Ian! On Thu, Jul 7, 2011 at 9:33 AM, Tomasz Finc wrote: > On Thu, Jul 7, 2011 at 1:11 AM, K. Peachey wrote: > > On Thu, Jul 7, 2011 at 5:27 PM, Alolita Sharma > wrote: > >> ...snip > >> engineer, welder, machinist, fire performer, drug educator, EMT, and > >> photographer. And he also enjoys flower arrangement and aerial > >> acrobatics. Wow - that’s a lot of cool interests :-) > > Hello and welcome > > > > Fire Performer? Aerial Acrobatics? that could make for some > > interesting wiki meetups and hack-a-thons > > Especially since we have a couple more aerialists/performers already here > :) > > Welcome Ian! > > --tomasz > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Arthur Richards Software Engineer Fundraising/Features/Offline/Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WMF Staff] Welcoming Ian Baker
On Thu, Jul 7, 2011 at 12:29 AM, Alolita Sharma wrote: > Ian's been a software developer for about 15 years. He's worked on > projects like the first open-source web framework, a billing system > for a regional ISP, a custom video transcoding system, and a > sensor-based flamethrower controller. This reflects a change in our requirements for new hires, in response to the Board resolution on openness, which requires us to "work with colleagues to develop practices to discourage disruptive and hostile behavior, and repel trolls and stalkers." If you don't know how to operate a flamethrower ... j/k -- welcome, Ian! Great to have you on-board :-) -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wiki markup lacks HTML precision anchors
On Wed, Jul 6, 2011 at 11:27 PM, Alexander wrote: > IIRC, all modern browsers support hash linking to any element with an id > attribute. Where "modern" means something like "since IE5", yes. All browsers we care about even slightly support linking to id's, and most browsers we don't care about even slightly do too. On Thu, Jul 7, 2011 at 12:52 AM, Daniel Friesen wrote: > Yes, in fact that's the standard. The standard has been id="" since > XHTML. HTML5 continues it, name="" is gone. Only ancient HTML4 used name=""> and it's only used in obsolete browsers now. More precisely, still works fine in all browsers, as required by HTML5, and will continue to work forever in all browsers. HTML5 defines as "obsolete but conforming", so validators will raise a warning but not an error: http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#warnings-for-obsolete-but-conforming-features ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Do we need Selenium for anything anymore? (was: [Selenium] IDE test for regressing bug)
On Thu, Jul 7, 2011 at 8:28 AM, Chad wrote: > On Thu, Jul 7, 2011 at 11:23 AM, Sumana Harihareswara > wrote: > > Thanks for the test & test suite! Just wanted to update you that it > seems > > like fewer and fewer MediaWiki developers are interested in Selenium > tests, > > and many are moving to other tools for automatic testing: > > > > That being said: is there any reason to leave the Selenium support in > core anymore? > I believe work still needs to be done to provide a test harness that uses QUnit for 'live-wiki' tests -- the current QUnit tests are standalone and run from static files, so can't test interaction with server-side behavior. With our current QUnit tests you can see if your JS code does something on some input data or HTML you construct, but you can't, say, confirm that issuing a click event on the watch tab submits an API request and comes back with the expected result. Interaction tests also tend to modify data -- by performing edits, creating accounts, changing settings, deleting things, undeleting things, etc. So, like the parser & phpunit tests that are potentially destructive, they either need to run on dedicated testing sites where that's acceptible, or the test harness needs to be able to set up / tear down a temporary wiki copy. Unlike the parser & unit tests, that temporary copy has to be actually exposed via the web so client-side tests can run. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Do we need Selenium for anything anymore? (was: [Selenium] IDE test for regressing bug)
Hello everybody, that's also the way I see it. Selenium tests do test the application as a whole. While I agree that a lot of things that are currently tested with Selenium can be substituted with QUnit or similar, I still think that selenium tests should be used to check more complex interaction patterns. In BlueSpice, an extension I am maintaining, we use Selenium e.g. to test a file uploader or GUI elements that interact via AJAX with the server. Also, keep in mind that selenium tests are quite easy to record. While experienced developers like us probably tend to write the tests instead of recording, I think that we can actually reduce the barrier for others. Regarding the core code, I think we could easily remove the autoloader references from the core since they can be put into the SeleniumFramework itself. However, there is a call to includes/SeleniumWebSettings.php right after LocalSettings are loaded. This file's task is to reconfigure the wiki and its database and files when it is under test in order to start with a fresh or otherwise defined state. This mechanism is not specific to selenium, although currently only used by SeleniumFramework. For Selenium tests to make sense, I suggest this mechanism should stay in core. However, we could rename it to something more descriptive. Btw, there will be a panel in Haifa where we want to discuss the test environment as a whole, if anyone's interested :) Cheers, Markus -Ursprüngliche Nachricht- Von: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Brion Vibber Gesendet: Donnerstag, 7. Juli 2011 19:43 An: Wikimedia developers Betreff: Re: [Wikitech-l] Do we need Selenium for anything anymore? (was: [Selenium] IDE test for regressing bug) On Thu, Jul 7, 2011 at 8:28 AM, Chad wrote: > On Thu, Jul 7, 2011 at 11:23 AM, Sumana Harihareswara > wrote: > > Thanks for the test & test suite! Just wanted to update you that it > seems > > like fewer and fewer MediaWiki developers are interested in Selenium > tests, > > and many are moving to other tools for automatic testing: > > > > That being said: is there any reason to leave the Selenium support in > core anymore? > I believe work still needs to be done to provide a test harness that uses QUnit for 'live-wiki' tests -- the current QUnit tests are standalone and run from static files, so can't test interaction with server-side behavior. With our current QUnit tests you can see if your JS code does something on some input data or HTML you construct, but you can't, say, confirm that issuing a click event on the watch tab submits an API request and comes back with the expected result. Interaction tests also tend to modify data -- by performing edits, creating accounts, changing settings, deleting things, undeleting things, etc. So, like the parser & phpunit tests that are potentially destructive, they either need to run on dedicated testing sites where that's acceptible, or the test harness needs to be able to set up / tear down a temporary wiki copy. Unlike the parser & unit tests, that temporary copy has to be actually exposed via the web so client-side tests can run. -- brion ___ 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 r91608]: New comment added
User "Brion VIBBER" posted a comment on MediaWiki.r91608. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91608#c19316 Commit summary: * (bug 28626) Validate JavaScript files and pages loaded via ResourceLoader before minification, protecting separate modules from interference This is possibly not perfect but seems to serve for a start; follows up on r91591 that adds JSMin+ to use it in some unit tests. May want to adjust some related bits. - $wgResourceLoaderValidateJs on by default (can be disabled) - when loading a JS file through ResourceLoaderFileModule or ResourceLoaderWikiModule, parse it using JSMinPlus's JSParser class. If the parser throws an exception, the JS code of the offending file will be replaced by a JS exception throw listing the file or page name, line number (in original form), and description of the error from the parser. - parsing results are cached based on md5 of content to avoid re-parsing identical text - for JS pages loaded via direct load.php request, the parse error is thrown and visible in the JS console/error log Issues: - the primary use case for this is when a single load.php request implements multiple modules via mw.loader.implement() -- the loader catches the exception and skips on to the next module (good) but doesn't re-throw the exception for the JS console. It does log to console if present, but it'll only show up as a regular debug message, not an error. This can suppress visibility of errors in a module that's loaded together with other modules (such as a gadget). - have not done performance testing on the JSParser - have not done thorough unit testing with the JSParser Comment: The file name and line number are already included in the exception message. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91642]: New comment added
User "MarkAHershberger" posted a comment on MediaWiki.r91642. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91642#c19317 Commit summary: Bug #29755: Apply patch from Vitaliy Filippov so that MW's HTTP client respects no_proxy env setting Comment: I didn't look as thoroughly as I should have and missed a few basic things as Bryan pointed out. However, Nikerabbit is right: the code review process is missing from Bugzilla patches. This one looked especially good -- at least the functionality of it. And Code Review sprang into action soon after I made the commit. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91608]: New comment added
User "Bryan" posted a comment on MediaWiki.r91608. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91608#c19318 Commit summary: * (bug 28626) Validate JavaScript files and pages loaded via ResourceLoader before minification, protecting separate modules from interference This is possibly not perfect but seems to serve for a start; follows up on r91591 that adds JSMin+ to use it in some unit tests. May want to adjust some related bits. - $wgResourceLoaderValidateJs on by default (can be disabled) - when loading a JS file through ResourceLoaderFileModule or ResourceLoaderWikiModule, parse it using JSMinPlus's JSParser class. If the parser throws an exception, the JS code of the offending file will be replaced by a JS exception throw listing the file or page name, line number (in original form), and description of the error from the parser. - parsing results are cached based on md5 of content to avoid re-parsing identical text - for JS pages loaded via direct load.php request, the parse error is thrown and visible in the JS console/error log Issues: - the primary use case for this is when a single load.php request implements multiple modules via mw.loader.implement() -- the loader catches the exception and skips on to the next module (good) but doesn't re-throw the exception for the JS console. It does log to console if present, but it'll only show up as a regular debug message, not an error. This can suppress visibility of errors in a module that's loaded together with other modules (such as a gadget). - have not done performance testing on the JSParser - have not done thorough unit testing with the JSParser Comment: But those are the line number in the concatenated file, right? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91608]: New comment added
User "Brion VIBBER" posted a comment on MediaWiki.r91608. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91608#c19319 Commit summary: * (bug 28626) Validate JavaScript files and pages loaded via ResourceLoader before minification, protecting separate modules from interference This is possibly not perfect but seems to serve for a start; follows up on r91591 that adds JSMin+ to use it in some unit tests. May want to adjust some related bits. - $wgResourceLoaderValidateJs on by default (can be disabled) - when loading a JS file through ResourceLoaderFileModule or ResourceLoaderWikiModule, parse it using JSMinPlus's JSParser class. If the parser throws an exception, the JS code of the offending file will be replaced by a JS exception throw listing the file or page name, line number (in original form), and description of the error from the parser. - parsing results are cached based on md5 of content to avoid re-parsing identical text - for JS pages loaded via direct load.php request, the parse error is thrown and visible in the JS console/error log Issues: - the primary use case for this is when a single load.php request implements multiple modules via mw.loader.implement() -- the loader catches the exception and skips on to the next module (good) but doesn't re-throw the exception for the JS console. It does log to console if present, but it'll only show up as a regular debug message, not an error. This can suppress visibility of errors in a module that's loaded together with other modules (such as a gadget). - have not done performance testing on the JSParser - have not done thorough unit testing with the JSParser Comment: No, the JS parser is being run over the original non-concatenated files as they're fetched, so the filename (actual file or wiki page title) and line number will be for the original source. Note that if we wanted to just switch to using JSMin+ as the minifier, we'd have three options: * continue to do an explicit parse run on each file just for error-checking purposes, then run JSMin+ to parse & minify the concatenated batch (problem: double parsing is slower) * minify the individual files separately before concatenation, so parse errors can get reported individually (problem: may require more retooling of ResourceLoader, which applies minification as a filter on top of multiple things already concatenated together) * parse each file separately, then combine the parse trees and minify based on that (problems: all the retooling pain from above, plus more ;) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] [Selenium] IDE test for regressing bug
Hi Sumana, Sure I would be interestd in writing tests with other tools. I like the record and play option in Selenium IDE to get a feel for the code. I am seeing that TestSwarm is a possible tool that the developers are using. Is there a tool with more of a record and play option, that will not interfere with the pages, to use and become familiar with the code? Feel free to email me offline too. Michelle Knight -- Message: 4 Date: Thu, 7 Jul 2011 11:23:30 -0400 From: Sumana Harihareswara Subject: Re: [Wikitech-l] [Selenium] IDE test for regressing bug https://bugzilla.wikimedia.org/show_bug.cgi?id=29310 To: Wikimedia developers , mknight1...@gmail.com Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Michelle: Thanks for the test & test suite! Just wanted to update you that it seems like fewer and fewer MediaWiki developers are interested in Selenium tests, and many are moving to other tools for automatic testing: http://www.mediawiki.org/wiki/Requests_for_comment/Unit_testing http://www.mediawiki.org/wiki/Test_framework_deployment#Status:_Permanent_hiatus http://www.mediawiki.org/wiki/Selenium_Framework#Selenium.27s_uses_.26_flaws Would you be interested in writing test suites or tests for some of these other tools? Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Heads-up: WMF engineering process improvement meetings
Erik Moeller wrote: > Following initial conversations, the purpose of the meeting tomorrow > is to do a deep-dive into a specific problem set: the code review, > deployment and release management process. We'll be digging into > questions like: > > 1) What are the best methods to ensure we keep up with the backlog > while still maintaining a good clip of WMF priority development; > 2) What's a realistic deployment and release cycle to shoot for (for > trunk, extensions, branches); > 3) How do we dissipate key skills more widely among both staff and > volunteers (e.g. deployment, security reviews); > 4) How/when can we split "big hairy projects" with integration issues > into more manageable chunks; > 5) What other high priority improvements do we need to prioritize > (e.g. increased test coverage, improvements to the testing frameworks, > het-deploy, staging environments, etc.) > > We're intentionally keeping this first meeting at a manageable size to > have a high face-to-face throughput and to explore where ThoughtWorks > can best help us. But I'm very much intending to make our thinking > public, and to form clear and visible groups around core problems > we're tackling, just as we have been doing with all WMF engineering > projects. So, I'll keep you posted, and if you have thoughts that > you'd like to post ahead of time, please do it onlist or offlist :-) Thanks very much for the heads-up. Posting the minutes or any notes from the meeting on Meta-Wiki or mediawiki.org would be fantastic. I might say that one more point to focus on specifically is to how to leverage volunteer development (this is hinted at in some of your five points). There are _a lot_ of people who are capable of coding in PHP and who are willing to donate their time and talents, but Wikimedia/MediaWiki code development has chased them off, generally through neglect (patches sitting, review sitting, etc.). If there are ways to specifically look at that, it would be an enormous benefit to Wikimedia/MediaWiki, I think. Much like the wikis themselves, you can rely on people to do good work if there's a support structure in place. The only caution is that, of course, if patches and commits increase without additional review/deployment support, you just make the problem worse (backlogs and frustration grow). Still, it seems that a huge issue is that volunteer time and talent is being wasted, so I think that's a fairly high priority (or at least should be). I'm really glad that these issues are being looked at. I know that a lot of people in the community (end-users and people related to the software development) have become frustrated with the speed of code review/development/time-to-new-features, so any step in a better direction is fantastic. :-) MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Postmortem for the MediaWiki 1.17 release
Rob Lanphier wrote:
> As noted, the biggest area for improvement is around the timing and
> release process. It wasn't all bad; we did (just barely) manage to
> keep the release cycle under one year. Still, that's much longer than
> our aspiration of quarterly releases, or even the previous historic
> norm of 2-3 releases per year. Moreover, it has been a long time
> since branching 1.17, so we already have seven months worth of work
> backed up for future releases. 1.18 was branched in early May, so in
> addition to the five months of changes we have backed up for that
> release, we already have two more months of changes backed up for
> 1.19.
[...]
> The first issue is purely one of scoping. Right now, we're not
> terribly deliberate about what goes in and what is out. Part of the
> problem we have here is that opinions vary as to what a reasonable
> release interval is. The range of opinion seems to be anywhere from
> "multiple times a day" to "every six months". It's difficult to plan
> this without getting consensus on this point, and it's difficult to
> get consensus without first proving that we can get on top of the code
> review backlog and stay on top of it. If we go with a longer cycle,
> we can consider adopting a process similar to GNOMEExample of
> GNOME release timeline: http://live.gnome.org/ThreePointOne or
> Ubuntu or other project that has a good track record for sticking with
> a regular releases. The most interesting practices there involve
> having clear deadlines for proposing new features, deadlines for
> features being done or pulled, and other date-risk mitigation
> strategies.
Thank you for writing all of this up. It looks like it probably took quite a
bit of time, and I appreciate it.
I pulled out two paragraphs that seem to be the nuggets. Without having this
thread devolve into another chase-your-tail thread, I'd say that the main
issue is that the release manager for 1.17 has a much more conservative
approach, and when looking at it from that lens, 1.17 was right on time.
Tim has outlined on this mailing list why he believes that more infrequent
releases are better, and his arguments are not necessarily invalid, I just
don't think they have any consensus behind them. I think Wikimedia and other
MediaWiki users would like a faster release process. But that's _completely
irrelevant_ when it's one person doing the work and putting together the
final release.
That, in a nutshell, seems to be the point of contention. The release (and
deployment!) timelines are perfectly aligned with a conservative approach,
but a lot of others (Brion, Neil, Chad, Roan, and in some ways Erik, among
others) have recommended a less conservative approach ("perfect is the enemy
of the done") that I believe would keep end-users and developers much
happier.
There's been a recent change-up in Wikimedia staffing, so I don't know who
will be managing the 1.18 release, but if it's the same person, my bet is
that it's going to take the same amount of time. In my view, a few people
(one?) see the longer release/deployment period as a feature, while the
majority of people see it as a bug. :-)
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Postmortem for the MediaWiki 1.17 release
On 7 July 2011 20:55, MZMcBride wrote: > Tim has outlined on this mailing list why he believes that more infrequent > releases are better, and his arguments are not necessarily invalid, I just > don't think they have any consensus behind them. I think Wikimedia and other > MediaWiki users would like a faster release process. But that's _completely > irrelevant_ when it's one person doing the work and putting together the > final release. Are we talking about WMF deployments or tarballs here? Speaking as a tarball user, 2 releases a year, maybe 3, is *just fine*. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r90904]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r90904. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90904#c0 Commit summary: Localisation updates for ToolserverI18N messages from translatewiki.net (2011-06-27 20:14:00) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90997]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r90997. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90997#c0 Commit summary: Localisation updates for ToolserverI18N messages from translatewiki.net (2011-06-28 21:03:00) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91099]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r91099. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91099#c0 Commit summary: Localisation updates for ToolserverI18N messages from translatewiki.net (2011-06-29 19:43:00) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91282]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r91282. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91282#c0 Commit summary: Localisation updates for ToolserverI18N messages from translatewiki.net (2011-07-01 19:35:00) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87704]: New comment added, and revision status changed
User "Krinkle" changed the status of MediaWiki.r87704. Old Status: deferred New Status: ok User "Krinkle" also posted a comment on MediaWiki.r87704. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87704#c19320 Commit summary: Updating 'qqq'-messages of TS project CommonsHelper2 Comment: Please make future modifictions to messages through translatewiki.net, keeps the commit history clean, makes it easier for translators to track changes and puts review of messages in the hands where it belongs (ie. not developers) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87709]: New comment added, and revision status changed
User "Krinkle" changed the status of MediaWiki.r87709. Old Status: deferred New Status: ok User "Krinkle" also posted a comment on MediaWiki.r87709. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87709#c19321 Commit summary: Update messages for CommonsHelper2 Comment: Except for modifications to English ofcourse, those can only be done from SVN. Thanks! ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87710]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r87710. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87710#c0 Commit summary: Update messages for CommonsHelper2 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87882]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r87882. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87882#c0 Commit summary: Update messages for CommonsHelper2 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91367]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r91367. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91367#c0 Commit summary: Localisation updates for ToolserverI18N messages from translatewiki.net (2011-07-02 20:42:00) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91380]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r91380. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91380#c0 Commit summary: Localisation updates for ToolserverI18N messages from translatewiki.net (2011-07-03 19:45:00) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91586]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r91586. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91586#c0 Commit summary: Localisation updates for ToolserverI18N messages from translatewiki.net (2011-07-06 19:17:00) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91673]: New comment added
User "Nikerabbit" posted a comment on MediaWiki.r91673. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91673#c19322 Commit summary: Moving cologneblue.css and nostalgia.css into their own folder Comment: svn move please? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91642]: New comment added
User "VitaliyFilippov" posted a comment on MediaWiki.r91642. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91642#c19323 Commit summary: Bug #29755: Apply patch from Vitaliy Filippov so that MW's HTTP client respects no_proxy env setting Comment: Thanks for review! I didn't expect it in trunk that fast :) What's the IP class? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91673]: Revision status changed
User "Bryan" changed the status of MediaWiki.r91673. Old Status: new New Status: fixme Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91673#c0 Commit summary: Moving cologneblue.css and nostalgia.css into their own folder ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91642]: New comment added
User "Bryan" posted a comment on MediaWiki.r91642. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91642#c19324 Commit summary: Bug #29755: Apply patch from Vitaliy Filippov so that MW's HTTP client respects no_proxy env setting Comment: The IP class in includes/IP.php defines helper functions, which should be mostly compatible with both IPv4 and IPv6. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Postmortem for the MediaWiki 1.17 release
On Thu, Jul 7, 2011 at 10:02 PM, David Gerard wrote: > Are we talking about WMF deployments or tarballs here? Speaking as a > tarball user, 2 releases a year, maybe 3, is *just fine*. > I think 3 releases per year is fine. However, I think we should deploy to WMF sites much more often than that. That's basically been my position throughout this debate. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91673]: New comment added
User "DieBuche" posted a comment on MediaWiki.r91673. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91673#c19325 Commit summary: Moving cologneblue.css and nostalgia.css into their own folder Comment: "svn move is equivalent to an svn copy followed by svn delete." ( http://svnbook.red-bean.com/en/1.0/re18.html ) AFAIK there's no clean move command like in git ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91673]: New comment added
User "Reedy" posted a comment on MediaWiki.r91673. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91673#c19326 Commit summary: Moving cologneblue.css and nostalgia.css into their own folder Comment: Indeed. But you've lost the history on these files So it's more like you've done cp, svn delete old, svn add new ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91581]: Revision status changed
User "Bryan" changed the status of MediaWiki.r91581. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91581#c0 Commit summary: Partial revert of r91106: followup to r91127. Suppressing all warning output from unserialize() in ExifBitmap::formatMetadata will hide actual errors; we're now checking explicitly for the bad-metadata and no-metadata markers so the case this was added for should not happen. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91642]: New comment added
User "Hashar" posted a comment on MediaWiki.r91642. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91642#c19327 Commit summary: Bug #29755: Apply patch from Vitaliy Filippov so that MW's HTTP client respects no_proxy env setting Comment: You can look it up on http://svn.wikimedia.org/doc/ or use the link: http://svn.wikimedia.org/doc/classIP.html IP::isIPAddress() should do it. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Postmortem for the MediaWiki 1.17 release
On Thu, Jul 7, 2011 at 10:18 PM, Roan Kattouw wrote: > On Thu, Jul 7, 2011 at 10:02 PM, David Gerard wrote: >> Are we talking about WMF deployments or tarballs here? Speaking as a >> tarball user, 2 releases a year, maybe 3, is *just fine*. >> > I think 3 releases per year is fine. However, I think we should deploy > to WMF sites much more often than that. That's basically been my > position throughout this debate. > +1 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Postmortem for the MediaWiki 1.17 release
David Gerard wrote: > On 7 July 2011 20:55, MZMcBride wrote: >> Tim has outlined on this mailing list why he believes that more infrequent >> releases are better, and his arguments are not necessarily invalid, I just >> don't think they have any consensus behind them. I think Wikimedia and other >> MediaWiki users would like a faster release process. But that's _completely >> irrelevant_ when it's one person doing the work and putting together the >> final release. > > Are we talking about WMF deployments or tarballs here? Speaking as a > tarball user, 2 releases a year, maybe 3, is *just fine*. As far as I'm aware, tarball releases and Wikimedia deployments have largely shifted to being at approximately the same (slower) pace, but they're not synchronized. But you're absolutely right that there's no need for that to be the case. I'm muddying the waters a bit by discussing both releases and deployments at once, and for that I apologize. That said, they are obviously interconnected. Ideally you want code (Wikimedia deployments) that has been run in the wild for a while in order to catch issues that would never be caught in development. That makes for a better tarball release. In this case, you also largely have the same person filling both roles (currently? I don't know). That is, Tim was the 1.17 release manager and he was the point-person doing the 1.17 deployment, as far as I remember, at least. As I said in my previous post, there have been some shifts in job titles (cf. Erik's e-mail a few weeks ago), which I think correlate to some shifts in job responsibilities, but that's still unclear to me. For what it's worth, I agree that two or three tarball releases per year would be fine, that just means getting Wikimedia deployments off of the same schedule. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikipedia dump (20110620) is 5.8G whereas previous dump(20110526) is 6.8G
Hi, The dump under "Recombine articles, templates, image descriptions, and primary meta-pages" is 6.8GB in http://dumps.wikimedia.org/enwiki/20110526/ page, whereas the same dump here http://dumps.wikimedia.org/enwiki/20110620/ page is 5.8GB. To be more accurate: http://download.wikimedia.org/enwiki/20110620/enwiki-20110620-pages-articles.xml.bz2 (5.8GB) vs http://download.wikimedia.org/enwiki/20110526/enwiki-20110526-pages-articles.xml.bz2 (6.8GB) Any idea why we have such a big difference? Thanks ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91664]: New comment added
User "Reedy" posted a comment on MediaWiki.r91664. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91664#c19328 Commit summary: ClickTracking: Add support for logging events to files or UDP through $wgClickTrackingLog. Also allow disabling database logging through $wgClickTrackingDatabase. Smaller tweaks: * Change $eventId parameter of ClickTrackingHooks::trackEvent() to $eventName, and move the ID->name lookup into the if($wgClickTrackingDatabase) branch. This ensures the clicktracking DB tables are not written to if DB logging is disabled. This function is public, but has no callers outside this extension * Change the type of the 'namespacenumber' parameter in the API module to 'integer'. It was previously set to 'namespace', which barfs on negative values, which caused nasty errors when an event happened to originate on a special page Comment: Don't you need another $dbw->begin() before you start doing the second set of queries? As you've already called commit.. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91664]: New comment added
User "Catrope" posted a comment on MediaWiki.r91664. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91664#c19329 Commit summary: ClickTracking: Add support for logging events to files or UDP through $wgClickTrackingLog. Also allow disabling database logging through $wgClickTrackingDatabase. Smaller tweaks: * Change $eventId parameter of ClickTrackingHooks::trackEvent() to $eventName, and move the ID->name lookup into the if($wgClickTrackingDatabase) branch. This ensures the clicktracking DB tables are not written to if DB logging is disabled. This function is public, but has no callers outside this extension * Change the type of the 'namespacenumber' parameter in the API module to 'integer'. It was previously set to 'namespace', which barfs on negative values, which caused nasty errors when an event happened to originate on a special page Comment: It probably does need that, yes, but that code wasn't introduced in this rev, only indented and wrapped in an if statement. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91572]: Revision status changed
User "Awjrichards" changed the status of MediaWiki.r91572. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91572#c0 Commit summary: updating for new country values ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91663]: New comment added
User "MZMcBride" posted a comment on MediaWiki.r91663.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91663#c19330
Commit summary:
(bug 29497) To support protocol-relative URLs in external links, add '//' to
$wgUrlProtocols and remove a useless \b in the bracketed external link regex in
the parser that prevented the former from working outright. With this change,
things like [//example.com/wiki/Foo Bar] are now supported, and
[[{fullurl:Foo|action=edit}} Bar] no longer breaks if $wgServer is set to
'//example.com' but produces a protocol-relative link instead.
Protocol-relative URLs in free text are not picked up and turned into [1] links
like URLs with protcols are; this is probably due to another \b somewhere, but
I think this is a good thing.
Comment:
Are there parser tests for this?
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88054]: New comment added
User "Bryan" posted a comment on MediaWiki.r88054. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88054#c19331 Commit summary: (bug 23002) Imagelinks table not updated after imagemove. The actual bug was inconsistent behaviour between imagelinks and pagelinks for redirects. * Parser now only adds the redirect source to imagelinks, like it does in pagelinks * ImagePage now shows the file redirects in-line with the normal "The following pages link to this file:" ** Added message linkstoimage-redirect ** Removed the separate file redirects section and removed associated message redirectstofile ** ImagePage::imageLinks will first fetch image links to the file, determine which are redirects, and if there are fewer links than the limit, fetch the redirect target links. Comment: I'm confused. Which hook? Can you point me to the file and the hook name? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Wikipedia dump (20110620) is 5.8G whereas previous dump(20110526) is 6.8G
Hi Sezgin, Ariel recently responded to a similar question on xmldatadumps-l: http://lists.wikimedia.org/pipermail/xmldatadumps-l/2011-July/000288.html Conrad On Thu, Jul 7, 2011 at 1:51 PM, Sezgin Sucu wrote: > Hi, > The dump under "Recombine articles, templates, image descriptions, and > primary meta-pages" is 6.8GB in > http://dumps.wikimedia.org/enwiki/20110526/ page, whereas the same > dump here http://dumps.wikimedia.org/enwiki/20110620/ page is 5.8GB. > > To be more accurate: > http://download.wikimedia.org/enwiki/20110620/enwiki-20110620-pages-articles.xml.bz2 > (5.8GB) > vs > http://download.wikimedia.org/enwiki/20110526/enwiki-20110526-pages-articles.xml.bz2 > (6.8GB) > > Any idea why we have such a big difference? > > Thanks > > ___ > 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 r91347]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r91347. Old Status: ok New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91347#c0 Commit summary: Correct for in loops on arrays. Reported in bug 29106. Patch by Michael M. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91596]: Revision status changed
User "Bryan" changed the status of MediaWiki.r91596. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91596#c0 Commit summary: * (bug 29745) Fatal error in API search Properly name objects being used ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91611]: Revision status changed
User "Bryan" changed the status of MediaWiki.r91611. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91611#c0 Commit summary: Followup r91609, helps to actually remove the @ ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91609]: Revision status changed
User "Bryan" changed the status of MediaWiki.r91609. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91609#c0 Commit summary: Bunch of error suppression operator fixes (bug ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90747]: Revision status changed
User "Bryan" changed the status of MediaWiki.r90747. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/90747#c0 Commit summary: getPath() does the wrong thing under SwiftMedia, but getRel() works for everything. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90745]: Revision status changed
User "Bryan" changed the status of MediaWiki.r90745. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/90745#c0 Commit summary: Had trouble distinguishing between these two error messages; the name was a null string hence the quotes. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91658]: Revision status changed
User "Reedy" changed the status of MediaWiki.r91658. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91658#c0 Commit summary: w/s fixup before patch ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91632]: Revision status changed
User "Reedy" changed the status of MediaWiki.r91632. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91632#c0 Commit summary: Partial revert of r90833, capitalisation change was not intented ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91674]: Revision status changed
User "Preilly" changed the status of MediaWiki.r91674. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91674#c0 Commit summary: added my userinfo file ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81499]: New comment added
User "Reedy" posted a comment on MediaWiki.r81499. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81499#c19332 Commit summary: Use the right query parameter. Comment: bug 29761 Postgres-based searching breaks between 1.13.1 and 1.17.0 These changes look to have been made before 1.18... But Roan merged it in r80190 from r78450 originally http://svn.wikimedia.org/viewvc/mediawiki/branches/REL1_17/phase3/includes/search/SearchPostgres.php?view=annotate ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r78450]: New comment added
User "Reedy" posted a comment on MediaWiki.r78450. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/78450#c19333 Commit summary: Changed doQuery() -> query() Comment: bug 29761 Postgres-based searching breaks between 1.13.1 and 1.17.0 These changes look to have been made before 1.18... But Roan merged it in r80190 from r78450 originally http://svn.wikimedia.org/viewvc/mediawiki/branches/REL1_17/phase3/includes/search/SearchPostgres.php?view=annotate ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91533]: Revision status changed
User "Preilly" changed the status of MediaWiki.r91533. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91533#c0 Commit summary: * RELEASE-NOTES for r90586. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91438]: Revision status changed
User "Preilly" changed the status of MediaWiki.r91438. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91438#c0 Commit summary: (follow-up r91436) add new hook to hooks.txt I totally updated the doc file, and then committed my other changes without the doc file. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91437]: Revision status changed
User "Preilly" changed the status of MediaWiki.r91437. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91437#c0 Commit summary: (follow-up r91436) Make this extension use the new hook i just made. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91436]: Revision status changed
User "Preilly" changed the status of MediaWiki.r91436. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91436#c0 Commit summary: (Follow-up r90759 per CR) Use a hook to register new Collations instead of just taking the collation name as a class name ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91300]: Revision status changed
User "Preilly" changed the status of MediaWiki.r91300. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91300#c0 Commit summary: Add lang & dir attributes to the sitenotice, in the site content language ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91668]: Revision status changed
User "Preilly" changed the status of MediaWiki.r91668. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91668#c0 Commit summary: Fixes Bug#17866 Minimal check that we have more than an empty string before sending and email. NikeRabbit asked me about LQT sending email to users w/o email addresses and this looked like one good place to add a check. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Heads-up: WMF engineering process improvement meetings
On Thu, Jul 7, 2011 at 12:40 PM, MZMcBride wrote: > Thanks very much for the heads-up. Posting the minutes or any notes from > the > meeting on Meta-Wiki or mediawiki.org would be fantastic. > We're taking notes on an etherpad for now; some process flowcharts are being done on a physical wall so once they're distilled onto the wiki w/ photos it should all be accessible together. I might say that one more point to focus on specifically is to how to > leverage volunteer development (this is hinted at in some of your five > points). There are _a lot_ of people who are capable of coding in PHP and > who are willing to donate their time and talents, but Wikimedia/MediaWiki > code development has chased them off, generally through neglect (patches > sitting, review sitting, etc.). If there are ways to specifically look at > that, it would be an enormous benefit to Wikimedia/MediaWiki, I think. > This is a big thing we want to solve -- current processes are very vague & laggy for a lot of stuff and only keep a fast deployment cycle for a few WMF-driven projects; this isn't because we're mean but because those are the only things that have internal drivers within WMF pushing them strongly enough; how to make sure other ongoing work gets the attention it needs too is very much on our minds. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91679]: New comment added, and revision status changed
User "NeilK" changed the status of MediaWiki.r91679. Old Status: new New Status: ok User "NeilK" also posted a comment on MediaWiki.r91679. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91679#c19334 Commit summary: removed dead code, updated version Comment: paired for these changes ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91694]: New comment added, and revision status changed
User "NeilK" changed the status of MediaWiki.r91694. Old Status: new New Status: ok User "NeilK" also posted a comment on MediaWiki.r91694. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91694#c19335 Commit summary: added early check for attempts to upload duplicate files. tested in chrome/ie6-xp/ie8-vista Comment: paired for these changes ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91660]: Revision status changed
User "Preilly" changed the status of MediaWiki.r91660.
Old Status: new
New Status: ok
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91660#c0
Commit summary:
Removing calls to deprecated functionality in favor of the new versions. Old
version worked fine but shouldn't be used.
Follows-up:
* r75275: Introduced the updateTooltipAccessKeys function in the new library
but didn't call it on document ready and left the deprecated one in the
onloadhook-run in wikibits.js untouched
* r75287: Introduced jquery.checkboxShiftClick and called on-load but left the
load call for the legacy version untouched. Depending on the load order at any
given time it may not have been used.
Also reordering the if-else case in mw.util.updateTooltipAccessKeys to allow a
call without arguments ("undefined instanceof Foo" throws exception)
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91650]: Revision status changed
User "Preilly" changed the status of MediaWiki.r91650. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91650#c0 Commit summary: Reduce some duplication ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91668]: New comment added
User "Bawolff" posted a comment on MediaWiki.r91668. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91668#c19336 Commit summary: Fixes Bug#17866 Minimal check that we have more than an empty string before sending and email. NikeRabbit asked me about LQT sending email to users w/o email addresses and this looked like one good place to add a check. Comment: I think there is a larger issue here involving confirming email. It should be impossible to send an email if your email is not verified. You can't verify an email if you don't have one set, so it should be impossible to get to this point if you don't have an email set. (Of course checking there is an email is probably a good sanity check nonetheless) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r76095]: New comment added, and revision status changed
User "Tim Starling" changed the status of MediaWiki.r76095. Old Status: deferred New Status: fixme User "Tim Starling" also posted a comment on MediaWiki.r76095. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/76095#c19337 Commit summary: wikimedia-task-appserver (1.46) hardy; urgency=low * Removed all configuration out of this package, into Puppet Comment: Apparently this is why dpkg is broken on searchidx1 at the moment. The postinst from libapache2-mod-php5 references /usr/share/php5/php.ini-dist, it dies if it is missing. The divert from before this change is still there, but the file was removed by a normal wikimedia-task-appserver upgrade. I guess the diversion removals should have been moved from purge) to remove), instead of just deleted. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r76095]: New comment added
User "Tim Starling" posted a comment on MediaWiki.r76095. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/76095#c19338 Commit summary: wikimedia-task-appserver (1.46) hardy; urgency=low * Removed all configuration out of this package, into Puppet Comment: I removed the diversion manually on searchidx1 so that my latest wikimedia-task-appserver upgrade could go through. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Bug solving metric?
Tim Landscheidt writes:
> is there any metric defined to see how the bug solving pro-
> cess has improved over time?
No, but you gave us a really good one:
> So is there any "scorecard" with more detailed data than the weekly
> report, i. e. minimum/average/maximum time to closure of
> bugs/non-bugs, some nice visualizations, etc.?
I think that is a great idea. I've been thinking about doing something
like this, but you've really concrete-ized it.
Now to your other concerns:
> The main reason I'm asking is today's two mails regarding
> bug #24000 ("Update rsvg so styling SVG images with CSS
> works properly on Commons"). Reported more than a year ago,
> the solution found early on was to update rsvg. I would have
> suspected that to do that you execute an "rpm -Uvh" equiva-
> lent on the server farm and close the bug.
As you suspect it isn't quite that easy.
Nevertheless this and a few other package upgrade bugs will are on the
list of items that Ops will probably be dealing with very soon.
I suggest that you use the newly created role of “Bugmeister” that I've
taken on. If you (or anyone else, for that matter) has a bug that
hasn't been dealt with, let me know and I'll do my best to get it to it
taken care of.
I'd like to have another method available than “bug the bugmeister” to
get these older bugs dealt with, but with almost 1600 open bugs, I'm
afraid I really don't have one (though, I'm open to any suggestions).
> From an outside perspective, this looks like (much) more energy is
> spent on managing the bugs than actually squashing them.
The intent of the bug triages and other Bugmeister activities (“managing
the bugs”) is to get developers to resolve them.
Note that another way I'm trying to resolve the bugs is by committing
patches that people have submitted and getting them applied faster.
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91642 shows the
result of this.
I didn't review this closely enough, but it ended up getting reviewed
really well by other developers and the submitter was still paying
attention (partly, I think) because of the quick application of his
patch.
Let me know if there is anything else you think I should be doing.
Mark.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91673]: Revision status changed
User "Hashar" changed the status of MediaWiki.r91673. Old Status: fixme New Status: reverted Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91673#c0 Commit summary: Moving cologneblue.css and nostalgia.css into their own folder ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Heads-up: WMF engineering process improvement meetings
On Thu, Jul 7, 2011 at 12:40 PM, MZMcBride wrote: > I might say that one more point to focus on specifically is to how to > leverage volunteer development (this is hinted at in some of your five > points). There are _a lot_ of people who are capable of coding in PHP and > who are willing to donate their time and talents, but Wikimedia/MediaWiki > code development has chased them off, generally through neglect (patches > sitting, review sitting, etc.). If there are ways to specifically look at > that, it would be an enormous benefit to Wikimedia/MediaWiki, I think. +1! There's an enormous pool of volunteer developers out there who would gladly work for us, non-stop, if we can find a way to let them. For many things, our templating language can be lot harder to work with than PHP-- but despite its difficulty, look at how many useful advanced templates have been developed without us even having to ask for them. Anyone who can make advanced templates can almost certainly handle PHP. The reason templates flourish while development flounders is "Openness"--- templating is essentially an open platform, WMF development is most certainly not an open platform. Volunteer developers will do ridiculous amounts of work for us, innovating in ways we can't even imagine. Google's most popular program is it's "20% time" that allows them to spend one day a week working on whatever they want. People want to innovate, just like people want to improve our projects' content. They will work for free-- but they have to know they'll be able to actually use their innovation themselves, and most have to know they can share it with others if it's popular. Most developers won't work for free only to have a third party decide whether it's sufficiently meritorious for its use to be allowed or not. Right now, there's system in place to allow me to initiate, develop, implement, and share a feature without having to deal with a lot of read tape and permission-getting. If I want a Wikipedia that's a little different in some way, I have to implement on the client-side or I literally have to make my own fork of Wikipedia, that involved buying a domain name, setting up a host, raising money for it / paying for it, etc etc etc. A huge nightmare full of work that developers don't enjoy. "Be Bold" hasn't been applied to the development or new projects yet. Right now, "Be Bold" is for an edits, not innovation. Right now, "Be Bold" is for new articles, not new projects. We meed to figure out how to allow developer innovations instantly, automatically, in real time. But we also have to make sure those innovations don't affect the user experience for third-parties. Once we get such a platform, development can take off. Until then, development will mostly be driven by third-party mediawiki project and paid staff-- both good to have, but orders of magnitude smaller than the size of the volunteer developer population that is going un-tapped. Alec ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
