[MediaWiki-CodeReview] [MediaWiki r108562]: New comment added
Nikerabbit posted a comment on MediaWiki.r108562. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108562#c29345 Commit summary for MediaWiki.r108562: (bug 33645) Translate popups don't deal with markup in summary field description. Nikerabbit's comment: Yes today. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105280]: New comment added
Fomafix posted a comment on MediaWiki.r105280. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105280#c29346 Commit summary for MediaWiki.r105280: Diff colors now use the french Wikipedia scheme The french community has been using a specific set of colors for diff, it is believed to be easier to read for people perceiving colors differently. Source is from: http://fr.wikipedia.org/w/index.php?oldid=72567845uselang=en This commit override r94429 / r94461. See also docs/uidesign/mediawiki.action.history.diff.html Fomafix's comment: Since r80495 tables have no more white background color. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108572]: New comment added
Hashar posted a comment on MediaWiki.r108572. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108572#c29347 Commit summary for MediaWiki.r108572: add js resource for concurrency api, check method for resource checkin checkout Hashar's comment: Reverted by r108601 . Manually added as a followup. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108560]: New comment added
Hashar posted a comment on MediaWiki.r108560. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108560#c29348 Commit summary for MediaWiki.r108560: Add svn:keywords Id Trim trailing whitespace Add explicit member variables Hashar's comment: Reverted by r108601 . Manually added as a followup. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108601]: New comment added
Hashar posted a comment on MediaWiki.r108601. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108601#c29349 Commit summary for MediaWiki.r108601: reverts Concurrency works trunk is frozen pending stabilisation so we can release MediaWiki 1.19. Those changes introduces API changes and new SQL tables, so that sounds like new feature we do not have time to review right now. Please reapply changes in branches/concurrency and have code review handled there. Once the branch has been reviewed, please hold. Once trunk is stable enough and 1.19 got branched, you are welcome to merge the branch in trunk. Note: we can have a Jenkins jobs setup to run the branch tests if you need. Reverts: r108595 r108591 r108585 r108584 108572 r108564 108560 r108559 Hashar's comment: Revision manually added as follow up of r108572 r108560. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107669]: New comment added
Hashar posted a comment on MediaWiki.r107669. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107669#c29350 Commit summary for MediaWiki.r107669: * more specific selectors for wikitable - don't inherit properties to nested tables which causes various rendering issues ** (bug 30485) Hieroglyphs look scary if embedded in tables with class=wikitable ** (bug 33434) math extension: integral expressions display with boxes/frames/borders Hashar's comment: Is that revision resolved with the follow up or should we revert it for now? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108568]: Revision status changed
Hashar changed the status of MediaWiki.r108568 to deferred
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108568
Old status: new
New status: deferred
Commit summary for MediaWiki.r108568:
More work towards template expansion.
* Created AttributeTokenTransformManager for generic attribute conversion, and
removed { title, template argument {key, value} } expansion from
TemplateHandler.
* Added caching for attribute and input sub-pipelines. Especially attribute
pipelines would otherwise be recreated for each attribute value and key.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r105076]: New comment added, and revision status changed
Jeroen De Dauw changed the status of MediaWiki.r105076 to ok and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105076#c29351 Old Status: deferred New Status: ok Commit summary for MediaWiki.r105076: follow-up r105066: makeKnownLinkObj() is deprecated Jeroen De Dauw's comment: Why was this deferred? Used on WMF wikis... ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108368]: Revision status changed
Hashar changed the status of MediaWiki.r108368 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108368 Old status: new New status: ok Commit summary for MediaWiki.r108368: * Improved error message for LockServerDaemon when parameters are missing and bumped default 'maxClients' value. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107376]: Revision status changed
Hashar changed the status of MediaWiki.r107376 to reverted URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107376 Old status: new New status: reverted Commit summary for MediaWiki.r107376: Added support for stored procedures/functions to MySQL: * Refactored DatabaseBase::sourceStream(), made it possible for descendant classes to alter its behaviour w/o having to redo it completely like Oracle does. * MySQL class now supports specifying DELIMITER. * Thrown away the mess of catering for double semicolon. If it's a problem, fix your .sql files! * Haven't actually touched Oracle. * Tests! ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107994]: Revision status changed
Hashar changed the status of MediaWiki.r107994 to reverted URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107994 Old status: ok New status: reverted Commit summary for MediaWiki.r107994: Follow-up r107376: disable test by default, causes failures in some configurations ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108603]: New comment added
Hashar posted a comment on MediaWiki.r108603. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108603#c29352 Commit summary for MediaWiki.r108603: Reverts MySQL stored procedure support This is reverting the work done by MaxSem to support stored procedures and stored function in MySQL. The reasons are: - it is not needed yet - tests are not functionals - alter the stable include/db/Database.php and drop support for ';;' So please create a branch to work on it and merge it back in trunk once we have branched 1.19 :-) I have opened bug 33654 to track this enhancement request. Reverts r107376, r107994. Hashar's comment: MaxSem please note I am not against stored procedures supports. But I think it is unlikely to get reviewed for 1.19 so it will most probably end up getting reverted anyway. Please keep up the work on it, if you need Jenkins to be setup to run test on the branch, let me know! ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108603]: New comment added
MaxSem posted a comment on MediaWiki.r108603. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108603#c29353 Commit summary for MediaWiki.r108603: Reverts MySQL stored procedure support This is reverting the work done by MaxSem to support stored procedures and stored function in MySQL. The reasons are: - it is not needed yet - tests are not functionals - alter the stable include/db/Database.php and drop support for ';;' So please create a branch to work on it and merge it back in trunk once we have branched 1.19 :-) I have opened bug 33654 to track this enhancement request. Reverts r107376, r107994. MaxSem's comment: It '''is''' needed for GeoData. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108603]: Revision status changed
MaxSem changed the status of MediaWiki.r108603 to fixme URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108603 Old status: new New status: fixme Commit summary for MediaWiki.r108603: Reverts MySQL stored procedure support This is reverting the work done by MaxSem to support stored procedures and stored function in MySQL. The reasons are: - it is not needed yet - tests are not functionals - alter the stable include/db/Database.php and drop support for ';;' So please create a branch to work on it and merge it back in trunk once we have branched 1.19 :-) I have opened bug 33654 to track this enhancement request. Reverts r107376, r107994. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108562]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108562 to reverted URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108562 Old status: fixme New status: reverted Commit summary for MediaWiki.r108562: (bug 33645) Translate popups don't deal with markup in summary field description. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Instructions for setting up regression tests on local machine?
Le Wed, 11 Jan 2012 02:31:47 +0100, Dan Nessett dness...@yahoo.com a écrit: Sure, I can post the results, but I don't think I should just dump them into this list (there are over 700 lines of output). How would you like me to go about it? You could open a bug report on https://bugzilla.wikimedia.org/ and attach the output. Or feel free to send it to Platonides and me, I can create the bug report for you. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r92703]: New comment added
Nikerabbit posted a comment on MediaWiki.r92703. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92703#c29354 Commit summary for MediaWiki.r92703: (bug 25355) Parser generates edit section links for special pages Per Tim on r58362: disable edit section links on all text parsed via $wgOut. Article already handles setting this to true for page content, so this shouldn't really hurt anything. Could use some tests to confirm the behavior, however. Should resolve the last problems with r70498 and friends. Nikerabbit's comment: I assume it is this revision that fixes all those annoying [edit] section links on special pages. Tagging for merging. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] New list: labs-l
On Tue, 10 Jan 2012 15:33:44 -0800, Ryan Lane rlan...@gmail.com wrote: To coordinate efforts occurring in Labs, and to be able to send/receive announcements, I've created a new labs-l list. If you are a labs member, or are interested in the work going on there, please subscribe: https://lists.wikimedia.org/mailman/listinfo/labs-l - Ryan Make sure it gets into gmane. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] JS load order, or: how to load a gadget before all others.
Hi all! What is the best way to control load order of JS (or modules modules in general)? We (WMDE) are developing WikiPraise, a gadget that can show directly show who contributed which part of a given article revision, as shown to the user. WikiPraise works by taking the wikitext annotated with authorship info (a blame map, currently provided by the CollaborativeTrust project), render it to html, then note the offsets of the marker in the generated html (ignoring markup and whitespace), and store them. When showing a page, the gadget fetches this authorship info and applies it to the html DOM of the content of the page. Thomas Schmidt (User:NetAction), who is developing WikiPraise for us, ran into a problem with other user scripts manipulating the DOM. Since we modify the DOM based on html offsets, any prior modification of the DOM will break the output. Thus, WikiPraise must run before any other JS that may modify the DOM. So, what would be the best way to achieve that? Perhaps we could write an extension that does nothing but causing the WikiPraise JS code to be loaded early enough? We could of course do the entire Wikitext-to-HTML transform on every page view, instead of trying to annotate the DOM based on a pre-generated, offset based blame map. But that would a) also have to happen before any other user script runs and b) would be prohibitively slow (try the WikiTrust plugin for firefox to see what i mean). Note that we plan to have this enabled per default even for anons. The idea is to provide an easy way for fully compliant re-use citing all authors of some section of an article, and also allowing readers to get a better idea who wrote what, and what can be trusted. Anyway: rendering the content based on the annotated wikitext on every page view would likely melt the servers, so it's not an option. We need to be able to apply some sort of pre-generated blame map to the DOM. Or, of course, we could hook into the parser and do all this inside mediawiki. We we'd need to call out to fetch or generate the blame map when parsing. If we had a high performance blame implementation that could be tightly integrated with mediawiki, this would work. I would prefer that, and we might work towards that, but it would be nice to have a low-impact implementation first. And the current approach works pretty well, except for other user scripts interfering. To try WikiPraise, put this into your common.js: $.holdReady(true); mediaWiki.loader.load(https://toolserver.org/~netaction/wikitrust.js;); Note that this will disable all gadgets and custom scripts: $.holdReady(true) is a hack to prevent other user scripts from running. That sucks of course. Any ideas? -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r108508]: New comment added
Moejoe000 posted a comment on MediaWiki.r108508. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108508#c29355 Commit summary for MediaWiki.r108508: reverts $wgDeprecationWhitelist There is no point in ignoring a deprecated function. The call really need to be migrated OR the core function should not be deprecated if there is any kind of valid usage. If you really want to hide notifications, uses: $wgDevelopmentWarnings = false; Reverts r106993 r106946 Moejoe000's comment: Reverts r106883 and r106946 (not r106993) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] JS load order, or: how to load a gadget before all others.
On Wed, Jan 11, 2012 at 12:19 PM, Daniel Kinzler dan...@brightbyte.de wrote: $.holdReady(true); mediaWiki.loader.load(https://toolserver.org/~netaction/wikitrust.js;); Note that this will disable all gadgets and custom scripts: $.holdReady(true) is a hack to prevent other user scripts from running. That sucks of course. I think holdReady is probably the most reliable way to prevent scripts from messing with your DOM, although I defer to Krinkle for a more authoritative answer. Writing an extension allows you to contrrol where WikiPraise's script tag will be put, but I'm not sure how much that'll help you. Do you need the clean DOM just for reading, or for writing as well? If you only need a clean DOM for reading and can write even to a dirty DOM, there are some alternatives: * hold the ready lock only for cloning the DOM, then release it and do your processing while other scripts run * use AJAX to fetch the HTML source of the page, and work with that It would be really nice if your blame engine didn't rely on character offsets in the HTML, but used something more robust. As you said, the preferred implementation would be something that's close to the parser and puts extra annotations (like span tags) in the parser-generated HTML (the InlineEditor extension does this). Server-side blaming doesn't have to be expensive as long as you use an incremental blame-as-you-go implementation where you store a blame map for each revision, and after each edit you use the edit diff and the previous revision's blame map to generate the new revision's blame map. This should be a fairly cheap edit-time operation. You would need to generate blame maps for all old revisions, though, but that could be done offline on a few high-performance boxes before the feature is even enabled. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r108577]: New comment added
Nikerabbit posted a comment on MediaWiki.r108577. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108577#c29356 Commit summary for MediaWiki.r108577: Remove use of deprecated LanguageGetMagic hook. Nikerabbit's comment: Only FIXME for CSS extension? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108593]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108593 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108593 Old status: deferred New status: ok Commit summary for MediaWiki.r108593: Follow-up to r108558 - added 'autoedit' to set of magic words ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108594]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108594 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108594 Old status: new New status: ok Commit summary for MediaWiki.r108594: added comment on improving PHP source parsing ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108594]: New comment added
Nikerabbit posted a comment on MediaWiki.r108594. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108594#c29357 Commit summary for MediaWiki.r108594: added comment on improving PHP source parsing Nikerabbit's comment: Sounds like a good idea. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] JS load order, or: how to load a gadget before all others.
Hi RoanDaniel! Do you need the clean DOM just for reading, or for writing as well? Read and write. WikiTrust does it very fast before the other scripts run. Then it releases the ready lock for all other scripts and adds its user interface. use AJAX to fetch the HTML source of the page, and work with that I did it. That doubled the traffic and destroyed most of the other scripts. Toggle TableOfContents, Maps and so on. It would be really nice if your blame engine didn't rely on character offsets in the HTML, but used something more robust. I did not see any error because of this so far. As long as we know what MediaWiki does we can be responsive on that. As you said, the preferred implementation would be something that's close to the parser and puts extra annotations (like span tags) in the parser-generated HTML You talk about up to several megabytes per page. Server-side blaming doesn't have to be expensive as long as you use an incremental blame-as-you-go implementation where you store a blame map for each revision, and after each edit you use the edit diff and the previous revision's blame map to generate the new revision's blame map. This is what Collaborativetrust already does. Unfortunately it does it not well. Thomas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r108597]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108597 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108597 Old status: new New status: ok Commit summary for MediaWiki.r108597: Rename Vemana telugu font to match its actual name and fix broken download link. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108602]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108602 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108602 Old status: new New status: ok Commit summary for MediaWiki.r108602: fix bug 16985 based on attached patch by Nakon ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108602]: New comment added, and revision status changed
Nikerabbit changed the status of MediaWiki.r108602 to new and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108602#c29358 Old Status: ok New Status: new Commit summary for MediaWiki.r108602: fix bug 16985 based on attached patch by Nakon Nikerabbit's comment: Not sure if I like 500 extra queries...can you make it do less? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108442]: Revision status changed
Santhosh.thottingal changed the status of MediaWiki.r108442 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108442 Old status: new New status: ok Commit summary for MediaWiki.r108442: $wgNarayamEnableByDefault was used for two different purposes. Renamed the newer function to another name ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108611]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108611 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108611 Old status: new New status: ok Commit summary for MediaWiki.r108611: Fixed reporting in importDump.txt ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] JS load order, or: how to load a gadget before all others.
On 11.01.2012 14:12, Thomas Schmidt wrote: Roan wrote: I think holdReady is probably the most reliable way to prevent scripts from messing with your DOM, although I defer to Krinkle for a more authoritative answer. Yes, unless they all use that :) My impression was that it breaks quite a few user scripts. But maybe I'm mistaken? I havn't tested the latest version extensively. If holdReady works well enough with other scripts, it's a good enough hack for now, I think. It would be really nice if your blame engine didn't rely on character offsets in the HTML, but used something more robust. I did not see any error because of this so far. As long as we know what MediaWiki does we can be responsive on that. I would love to use something more robust, yes, but it also has to be compact and fast. I can't think of anything offhand. Maybe As you said, the preferred implementation would be something that's close to the parser and puts extra annotations (like span tags) in the parser-generated HTML You talk about up to several megabytes per page. That'S not the main problem. The main problem is that we are doing this on thje outside. So, we would have a pre-calculated DOM with our annotations, and the DOM present on the page without our annotations, but possibly modified by scripts, and would have to merge the two. That only makes things wordse. Server-side blaming doesn't have to be expensive as long as you use an incremental blame-as-you-go implementation where you store a blame map for each revision, and after each edit you use the edit diff and the previous revision's blame map to generate the new revision's blame map. This would be my preferred solution, but it's way beyond the scope of the current project. The idea was to have a standalone script that works well enough to show that this kind of thing is indeed useful. If we have the foundation's support for developing full blame/praise support in mediawiki, I even know who would be not only delighted but also qualified to write it (not for free, though). But with wikidata coming up, I doubt wmde would manage the project. Though I personally would love to see this happening asap. In fact, I hope that some experience with the gadget based solution will convince the foundation that yes, we want that, we need that. Hm, actually... fellowships arn't supposed to be for development stuff, are they? This is what Collaborativetrust already does. Unfortunately it does it not well. Well, the blame map they generate is better than any I have seen so far, they deal nicely with moved paragraphs, reverts, etc. But the trust part is massive overhead, and it's ocaml. Otoh, integrating this into mediawiki directly as an extension was their original approach, some code already exists. Note that storing the blame maps for all revisions needs quite a bit of space. And yes, we need all revisions. cheers daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r108612]: New comment added, and revision status changed
Nikerabbit changed the status of MediaWiki.r108612 to ok and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108612#c29359 Old Status: new New Status: ok Commit summary for MediaWiki.r108612: Always add error messages to pages in content language Nikerabbit's comment: There is no verb in the method name. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108613]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108613 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108613 Old status: new New status: ok Commit summary for MediaWiki.r108613: fix typo causing table updates to fail ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108508]: Revision status changed
Jeroen De Dauw changed the status of MediaWiki.r108508 to reverted URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108508 Old status: fixme New status: reverted Commit summary for MediaWiki.r108508: reverts $wgDeprecationWhitelist There is no point in ignoring a deprecated function. The call really need to be migrated OR the core function should not be deprecated if there is any kind of valid usage. If you really want to hide notifications, uses: $wgDevelopmentWarnings = false; Reverts r106993 r106946 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108601]: Revision status changed
^demon changed the status of MediaWiki.r108601 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108601 Old status: new New status: ok Commit summary for MediaWiki.r108601: reverts Concurrency works trunk is frozen pending stabilisation so we can release MediaWiki 1.19. Those changes introduces API changes and new SQL tables, so that sounds like new feature we do not have time to review right now. Please reapply changes in branches/concurrency and have code review handled there. Once the branch has been reviewed, please hold. Once trunk is stable enough and 1.19 got branched, you are welcome to merge the branch in trunk. Note: we can have a Jenkins jobs setup to run the branch tests if you need. Reverts: r108595 r108591 r108585 r108584 108572 r108564 108560 r108559 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108503]: Revision status changed
^demon changed the status of MediaWiki.r108503 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108503 Old status: new New status: ok Commit summary for MediaWiki.r108503: StoreBatchText note about using custom repo follow up r108308 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] JS load order, or: how to load a gadget before all others.
2012/1/11 Daniel Kinzler dan...@brightbyte.de: The main problem is that we are doing this on thje outside. That would be a really great thing. When the user clicks a word we have to find out where he clicked. The data goes back to the server. The server finds out which scripts were used and generates the same HTML that is currently in the browser. Yes, it has to do something like executing the scripts. Then the server knows the revision of the clicked position. The server sends rules back to the browser how to highlight the text. I think it is not possible with less traffic and less memory consumption in the browser. But all the small DOM manipulations for inserting the just needed SPAN elements will be slower than the existing UserScript which manipulates the whole page in one innerHTML call. Yes, we could do all this on the client side with the help of the WikiTrust Sure sequences too. It will be a hard job to imitate all scripts in the hidden HTML but it is possible. But: Is there any advantage to the current UserScript? Thomas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r108618]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108618 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108618 Old status: new New status: ok Commit summary for MediaWiki.r108618: Stop using in_string(). WikiScripts and AbuseFilter are the only exts still using this silly thing. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108621]: Revision status changed
^demon changed the status of MediaWiki.r108621 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108621 Old status: new New status: ok Commit summary for MediaWiki.r108621: Kill bug 25355 RELEASE-NOTES-1.19 from r92703 as moved to 1.18 in r108620 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108620]: Revision status changed
^demon changed the status of MediaWiki.r108620 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108620 Old status: new New status: ok Commit summary for MediaWiki.r108620: MFT r92703, r94131 Move RELEASE-NOTES to 1.18 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108617]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108617 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108617 Old status: new New status: ok Commit summary for MediaWiki.r108617: Turn the feedback link on by default ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107947]: Revision status changed
Nikerabbit changed the status of MediaWiki.r107947 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107947 Old status: new New status: ok Commit summary for MediaWiki.r107947: Fix js error ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108147]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108147 to resolved URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108147 Old status: new New status: resolved Commit summary for MediaWiki.r108147: (bug 33456) show $wgQueryCacheLimit on cached query pages, so users know that the results are artificially cut off, and its not just that there is only 1000 wanted files (or whatever else) on the wiki. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107337]: Revision status changed
Reedy changed the status of MediaWiki.r107337 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107337 Old status: new New status: ok Commit summary for MediaWiki.r107337: * (bug 33366) ConfirmEdit: Disable autocorrect, autocapitalize on FancyCaptcha's input form to aid tablet users Autocorrect / autocapitalize could mess up your input data, making it harder to get through the captcha. Disabled it so what you type is what you get. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108170]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108170 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108170 Old status: new New status: ok Commit summary for MediaWiki.r108170: Followup r99891, clean up javascript ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107983]: Revision status changed
Nikerabbit changed the status of MediaWiki.r107983 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107983 Old status: new New status: ok Commit summary for MediaWiki.r107983: [mediawiki.debug] display: inline-block; work-around for in IE7 * display: inline-block; is not supported by IE7 * Using standard work-around with triggering hasLayout (via zoom: 1;) on an inline element (only for IE7 through *hack) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88118]: New comment added
Fomafix posted a comment on MediaWiki.r88118. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88118#c29360 Commit summary for MediaWiki.r88118: Fix Bug 28979 — “remove some CSS for abbr and acronym tags” The abbr and acronym tags were whitelisted with bug 671, but there are some CSS rules for them since long, long times. They can be found in the first versions of chick, monobook and are carried on to vector skin. Often these tags are used in links, e.g. [[Normalnull|abbr title=meter above see levelNN/abbr]]. But in here the color:black; makes the text unrecognizable as a hyperlink (together with the senseful cursor:help; rule). When these rules where meant to override some crazy browserdependent default settings, they should be be changed to inherit. from Bergi Fomafix's comment: syntaxhighlight lang=css border-bottom: 1px dotted black; /syntaxhighlight should be replaced by syntaxhighlight lang=css border-bottom: 1px dotted; /syntaxhighlight to get a border in the same color like the current text color: # span style=color:redred text with span style=border-bottom: 1px dotted blackborder-bottom: 1px dotted black/span./span # span style=color:redred text with span style=border-bottom: 1px dottedborder-bottom: 1px dotted/span./span * http://www.w3.org/TR/CSS2/box.html#border-color-properties ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107982]: New comment added
Nikerabbit posted a comment on MediaWiki.r107982. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107982#c29361 Commit summary for MediaWiki.r107982: [jquery.footHovzer] new plugin for mw-log-console and mw-debug-toolbar * Previously mw.log and mw.Debug both were in a fixed container on the bottom, overlapping each other. mw.log did increase the body's padding-bottom to account for the height so that all content is still visible, but it was still a problem when mw.Debug came along. * This plugin adds a single fixed position element to bottom of the body, to which other stuff like mw.log and mw.Debug can append a non-fixed position container. That will take care of it. * Method update() will re-check the padding and scroll position and fix where needed * Reduces code a little bit Nikerabbit's comment: Typo: focused + // Update scroll so that page stays focusses on same area ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107696]: Revision status changed
Nikerabbit changed the status of MediaWiki.r107696 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107696 Old status: new New status: ok Commit summary for MediaWiki.r107696: Follow-up r107695: strict checking on override_ogg might be required ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107649]: New comment added, and revision status changed
Nikerabbit changed the status of MediaWiki.r107649 to fixme and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107649#c29362 Old Status: new New Status: fixme Commit summary for MediaWiki.r107649: add aditional functionality Nikerabbit's comment: Lots of unescaped messages, and why is this reimplemeting wfParseUrl and wfAppendQuery? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r107508]: Revision status changed
Nikerabbit changed the status of MediaWiki.r107508 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107508 Old status: new New status: ok Commit summary for MediaWiki.r107508: * Use Linker::getRevDeleteLink() where possible to remove code duplication * Pass the User object to Revision::userCan() in Linker::getRevDeleteLink() * Return the result Linker::revDeleteLinkDisabled() in Linker::getRevDeleteLink() instead of storing it in a variable that will not be used ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108626]: Revision status changed
Krinkle changed the status of MediaWiki.r108626 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108626 Old status: new New status: ok Commit summary for MediaWiki.r108626: Revert r108345 out of r108625, also revert r94131 out of r108622 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108632]: Revision status changed
Krinkle changed the status of MediaWiki.r108632 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108632 Old status: new New status: ok Commit summary for MediaWiki.r108632: Add @since to getPerformedAction, added in r108342 Caused site errors as not in 1.18 when trying to merge r108345 as a followup to r94131 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108505]: Revision status changed
Catrope changed the status of MediaWiki.r108505 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108505 Old status: new New status: ok Commit summary for MediaWiki.r108505: Remove boneheaded non-use of insertId in AFTv5 (actually already being used, just not passed into saveUserProperties for some reason). follow up to r106965 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r106965]: Revision status changed
Catrope changed the status of MediaWiki.r106965 to resolved URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106965 Old status: fixme New status: resolved Commit summary for MediaWiki.r106965: AFTv5 - enable use of feedback properties table to store user edit counts (if user is logged in). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108506]: New comment added
Catrope posted a comment on MediaWiki.r108506. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108506#c29363 Commit summary for MediaWiki.r108506: AFTv5 fixes - consistent escaping of translations, fix typo in translations file, and assume values on the maxLength config variable. follow up to r108482 Catrope's comment: Fixed in r108635. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] New committer
Hi Robert, glad to see you around! Cheers, Markus -Ursprüngliche Nachricht- Von: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Sumana Harihareswara Gesendet: Mittwoch, 11. Januar 2012 02:26 An: Wikimedia developers Betreff: [Wikitech-l] New committer Robert Vogel (rvogel, User:Osnard) is a web developer at Hallo Welt! and works on WindowsAzureSDK, WindowsAzureStorage, ClientSyntaxHighlighter, BibManager, and (probably soon) PagedTiffHandler. He's receiving extensions access. Welcome, Robert! -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation ___ 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 r108506]: Revision status changed
Catrope changed the status of MediaWiki.r108506 to resolved URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108506 Old status: new New status: resolved Commit summary for MediaWiki.r108506: AFTv5 fixes - consistent escaping of translations, fix typo in translations file, and assume values on the maxLength config variable. follow up to r108482 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108615]: New comment added
Hashar posted a comment on MediaWiki.r108615. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108615#c29364 Commit summary for MediaWiki.r108615: revert r108508 which reverted for no good reason Hashar's comment: Will bring that to wikitech-l since I think this is broken and should not be merged. I already exposed the reason for the reversion. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] JS load order, or: how to load a gadget before all others.
- Original Message - From: Thomas Schmidt schm...@netaction.de As you said, the preferred implementation would be something that's close to the parser and puts extra annotations (like span tags) in the parser-generated HTML You talk about up to several megabytes per page. It was my snap reaction as well that putting span markers in the HTML at blame edges wasn't gonna scale very well... and could be pathological. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: wikicaptcha on GitHub
2012/1/6 Platonides platoni...@gmail.com: Integrating this into ConfirmEdit extension shouldn't be hard. It's the extra features what makes this tricky. This system is interesting for gathering translations, but doesn't work for verifying that the answer is right. How would you verify that? The approach that comes to my mkind is to show both the current captcha plus another, optional, captcha, with a note about how filling that second captcha helps wikisource, and that the answer will be logged with their username/ip. ReCAPTCHA already works in a way similar to this. Two words are presented but only one is known and actually serves to filtrate accesses. They then collect answers for both words and if the test on the first is passed (which indicates a human) then the answer for the second is recorded. When a certain number of people agree on the transcription of a previously unknown word then that transcription is taken as good and used in future as a filter word. We could say that we accept a transcription as valid after N people agrees on a given word and put back on Wikisource only the validated words (and also use them as filters, too) . This seems both a reliable and easy-to-implement system to me. Anyway, at the beginning we could use the system you describe using the current captcha and words from books. I believe the trickiest part is creating a system to put results back in Wikisource in a semi-automated way, but having captcha reviewers may help. We could also decorate our captcha with this captcha helps transcribing BOOK TITLE + link. And this leads me to what I think is the real point: once we have a basically-working system we can think to whatever useful feature and implement it, in principle we can have a modular system which can be refined /at libitum/. Cristian ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r108519]: Revision status changed
Catrope changed the status of MediaWiki.r108519 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108519 Old status: new New status: ok Commit summary for MediaWiki.r108519: Added edit click tracking: - modules/jquery.articleFeedbackv5/jquery.articleFeedbackv5.js: - New public method clickTrackingOn() - modules/ext.articleFeedbackv5/ext.articleFeedbackv5.js: - If click tracking is on, add tracking to the edit tab and section edit links - ArticleFeedbackv5.hooks.php: - Updated pushTrackingFieldsToEdit() to pass the edit click tracking event - Updated trackEvent() to look for the edit click tracking event and use it correctly ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Fwd: wikicaptcha on GitHub
On 11 January 2012 17:19, Cristian Consonni kikkocrist...@gmail.com wrote: We could also decorate our captcha with this captcha helps transcribing BOOK TITLE + link. Hah, use it for editor recruitment! - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New committer
Welcome, Robert! You and I should be crossing paths. I have everything working through version 1.18 on Windows Azure, except for the media storage. Right this moment I am trying to figure out how to get my code committed, but I have been struggling with setting up the Subversion access from my Windows 7 box. Any hints or pointers on how to set things up may help me transition from a potential to an actual contributer. On Tue, Jan 10, 2012 at 7:26 PM, Sumana Harihareswara suma...@wikimedia.org wrote: Robert Vogel (rvogel, User:Osnard) is a web developer at Hallo Welt! and works on WindowsAzureSDK, WindowsAzureStorage, ClientSyntaxHighlighter, BibManager, and (probably soon) PagedTiffHandler. He's receiving extensions access. Welcome, Robert! -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation ___ 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
Re: [Wikitech-l] Fwd: wikicaptcha on GitHub
2012/1/11 David Gerard dger...@gmail.com: On 11 January 2012 17:19, Cristian Consonni kikkocrist...@gmail.com wrote: We could also decorate our captcha with this captcha helps transcribing BOOK TITLE + link. Hah, use it for editor recruitment! That was the point, indeed. Cristian ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r108530]: Revision status changed
Catrope changed the status of MediaWiki.r108530 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108530 Old status: new New status: ok Commit summary for MediaWiki.r108530: Followup to r107914: added comment to explain how the link ID works ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108557]: Revision status changed
Catrope changed the status of MediaWiki.r108557 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108557 Old status: new New status: ok Commit summary for MediaWiki.r108557: Bumped down the fixed tab links' z-indexes so they fall below the modal overlay ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] New committer
Hi DJ Bauch, I had some trouble with TortoiseSVN and pageant recently after updating SVN to 1.7 (and the new svn format) on Win7. The solution for me was to update pageant to a current version (I think it was 0.62). Maybe this helps you as well? Regards, Markus -Ursprüngliche Nachricht- Von: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von DJ Bauch Gesendet: Mittwoch, 11. Januar 2012 18:26 An: Wikimedia developers Betreff: Re: [Wikitech-l] New committer Welcome, Robert! You and I should be crossing paths. I have everything working through version 1.18 on Windows Azure, except for the media storage. Right this moment I am trying to figure out how to get my code committed, but I have been struggling with setting up the Subversion access from my Windows 7 box. Any hints or pointers on how to set things up may help me transition from a potential to an actual contributer. On Tue, Jan 10, 2012 at 7:26 PM, Sumana Harihareswara suma...@wikimedia.org wrote: Robert Vogel (rvogel, User:Osnard) is a web developer at Hallo Welt! and works on WindowsAzureSDK, WindowsAzureStorage, ClientSyntaxHighlighter, BibManager, and (probably soon) PagedTiffHandler. He's receiving extensions access. Welcome, Robert! -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r102851]: New comment added
MaxSem posted a comment on MediaWiki.r102851. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102851#c29365 Commit summary for MediaWiki.r102851: * Renamed member variables to begin with a lower case * Moved constant definitions from the constructor to the class definition * Removed default values from the class definition for members that are always set in the constructor MaxSem's comment: I need this revision and its friend r102861 backported to release branch because FeaturedFeeds (ab)uses this class and consistency would really help. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] should we keep $wgDeprecationWhitelist
Hello, [r106883] introduces a new global setting to whitelist deprecated functions: $wgDeprecationWhitelist. Its documentation is: /** * Function name whitelist for wfDeprecated warnings. You will not be warned * for usage of deprecated functions in this list. This is mainly usefull * for extension developers unable to not use certain deprecated functions * due to backward compatinility reasons. * @since 1.19 * @var array */ I do not think we want such setting in core since it does not make sense. Developers can opt-in to get deprecation warnings shown, it is not to have them whitelisted later with yet another global. Either the extension need to be fixed or the core call should not be deprecated. So, I have reverted the change with [r106946]. That was then opposed a fuck you argument and reverted * I am not going to engage in a revision war. * I am not going to mark 'ok' a revision I feel is wrong. So this mail is merely asking for people to please have a look at the feature, comment on it and reach a consensus about whether we should or should not keep this setting. Thanks. [r106883] Introduced wgDeprecationWhitelist https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106883 [r106946] My reversion https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106946 -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r108615]: New comment added
Hashar posted a comment on MediaWiki.r108615. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108615#c29366 Commit summary for MediaWiki.r108615: revert r108508 which reverted for no good reason Hashar's comment: See http://lists.wikimedia.org/pipermail/wikitech-l/2012-January/057501.html ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108573]: New comment added, and revision status changed
Catrope changed the status of MediaWiki.r108573 to ok and commented it. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108573#c29367 Old Status: new New Status: ok Commit summary for MediaWiki.r108573: add concurrency call to feedback dashboard, revise loadConcurrencyToolTip method. follow up r108271 Catrope's comment: This is OK, but let's disable the concurrency stuff for now. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] should we keep $wgDeprecationWhitelist
Hey, That was then opposed a fuck you argument and reverted This seems to be quoting me out of context. Here is my full comment to Hashars revert of mine: -- Ok, apparently I need to explain this once more - sort of getting tired of it, this is why I send a flipping email to the list with my reasoning. Scenario: some interface gets changed for a valid reason in 1.19. You are an extension developer with an extension that needs to be compatible with 1.17 to 1.19. Now you do not have the time to put in code to handle both versions, which might be a lot of work depending on the interface change. So you want to ignore this usage of this detracted interface for now, and fix it later on. However, you want to get a warning as soon as you use some other detracted interface. To me this very much comes off as a fuck you to extension developers. -- I do not think we want such setting in core since it does not make sense. Developers can opt-in to get deprecation warnings shown, it is not to have them whitelisted later with yet another global. Either the extension need to be fixed or the core call should not be deprecated. You are suggesting this feature is useless. The scenario I used as an example proves it is for developers, that want to have an option between warnings and no warnings. I introduced the setting because I _needed_ it, and anticipate it to be useful for other people that have $wgDeprecationReleaseLimit set to false. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r108642]: New comment added
Santhosh.thottingal posted a comment on MediaWiki.r108642. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108642#c29368 Commit summary for MediaWiki.r108642: follow up to concurrency tool revert, remove dependant code. follow up r108600 Santhosh.thottingal's comment: r108600 is not related to this. It is webfonts extension fix. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Instructions for setting up regression tests on local machine?
On Wed, 11 Jan 2012 11:17:33 +0100, Antoine Musso wrote: Le Wed, 11 Jan 2012 02:31:47 +0100, Dan Nessett dness...@yahoo.com a écrit: Sure, I can post the results, but I don't think I should just dump them into this list (there are over 700 lines of output). How would you like me to go about it? You could open a bug report on https://bugzilla.wikimedia.org/ and attach the output. Or feel free to send it to Platonides and me, I can create the bug report for you. I have created a bug report (https://bugzilla.wikimedia.org/show_bug.cgi? id=33663) and attached the output to it. -- -- Dan Nessett ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r108578]: Revision status changed
Catrope changed the status of MediaWiki.r108578 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108578 Old status: new New status: ok Commit summary for MediaWiki.r108578: find and remove item concurrecny tooltip when closing feedback response form ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108454]: Revision status changed
Catrope changed the status of MediaWiki.r108454 to resolved URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108454 Old status: new New status: resolved Commit summary for MediaWiki.r108454: followup to -r108187 - Checking isset instead of 1/0 for checkbox, adding myresponse/showunanswered to query parameter ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108642]: Revision status changed
Catrope changed the status of MediaWiki.r108642 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108642 Old status: new New status: ok Commit summary for MediaWiki.r108642: follow up to concurrency tool revert, remove dependant code. follow up r108600 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108642]: New comment added
Robmoen posted a comment on MediaWiki.r108642. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108642#c29369 Commit summary for MediaWiki.r108642: follow up to concurrency tool revert, remove dependant code. follow up r108600 Robmoen's comment: oops, follow up to r108601 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108643]: Revision status changed
Catrope changed the status of MediaWiki.r108643 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108643 Old status: new New status: ok Commit summary for MediaWiki.r108643: remove concurrency resource per revert. follow up r108600 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] PHP 5.3.9 released (page says All users are strongly encouraged to upgrade to PHP 5.3.9.)
A new PHP version 5.3.9 has been released, see http://www.php.net/archive/2012.php#id2012-01-11-1 The page says All users are strongly encouraged to upgrade to PHP 5.3.9. Hints to compile ( ./configure options) for MediaWiki can be found here https://www.mediawiki.org/wiki/Extension:OpenID#cite_ref-compile-php_4-0 signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] PHP 5.3.9 released (page says All users are strongly encouraged to upgrade to PHP 5.3.9.)
On Wed, Jan 11, 2012 at 1:39 PM, Thomas Gries m...@tgries.de wrote: A new PHP version 5.3.9 has been released, see http://www.php.net/archive/2012.php#id2012-01-11-1 The page says All users are strongly encouraged to upgrade to PHP 5.3.9. They said almost the same thing for 5.3.1 too[0], and look how well that turned out ;-) -Chad [0] http://www.php.net/archive/2009.php#id2009-11-19-1 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] should we keep $wgDeprecationWhitelist
On Wed, Jan 11, 2012 at 12:45 PM, Antoine Musso hashar+...@free.fr wrote: I do not think we want such setting in core since it does not make sense. Developers can opt-in to get deprecation warnings shown, it is not to have them whitelisted later with yet another global. Either the extension need to be fixed or the core call should not be deprecated. I tend to agree that this isn't terribly useful, but I'm not willing to revert war over it. If we're voting, count me in the -1 column I suppose. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r107649]: Revision status changed
Preilly changed the status of MediaWiki.r107649 to new URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107649 Old status: fixme New status: new Commit summary for MediaWiki.r107649: add aditional functionality ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] should we keep $wgDeprecationWhitelist
On Wed, Jan 11, 2012 at 10:44 AM, Chad innocentkil...@gmail.com wrote: On Wed, Jan 11, 2012 at 12:45 PM, Antoine Musso hashar+...@free.fr wrote: I do not think we want such setting in core since it does not make sense. Developers can opt-in to get deprecation warnings shown, it is not to have them whitelisted later with yet another global. Either the extension need to be fixed or the core call should not be deprecated. I tend to agree that this isn't terribly useful, but I'm not willing to revert war over it. I tend to take the same position. :) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] should we keep $wgDeprecationWhitelist
Hey, I tend to agree that this isn't terribly useful, but I'm not willing to revert war over it. If we're voting, count me in the -1 column I suppose. I tend to take the same position. :) Did you read what I wrote? How is it not useful? Please provide REASONING, that proves my argument is invalid. If you cannot do this, you have no valid reason for shouting -1. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] should we keep $wgDeprecationWhitelist
On Wed, Jan 11, 2012 at 1:53 PM, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, I tend to agree that this isn't terribly useful, but I'm not willing to revert war over it. If we're voting, count me in the -1 column I suppose. I tend to take the same position. :) Did you read what I wrote? How is it not useful? Please provide REASONING, that proves my argument is invalid. If you cannot do this, you have no valid reason for shouting -1. Yes, I read what you wrote, I just happen to disagree with you. Please don't demand I make a mathematical proof of the universe making sense. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] PHP 5.3.9 released (page says All users are strongly encouraged to upgrade to PHP 5.3.9.)
Am 11.01.2012 19:42, schrieb Chad: A new PHP version 5.3.9 has been released, see http://www.php.net/archive/2012.php#id2012-01-11-1 The page says All users are strongly encouraged to upgrade to PHP 5.3.9. They said almost the same thing for 5.3.1 too[0], and look how well that turned out ;-) Security Enhancements and Fixes in PHP 5.3.9: * Added max_input_vars directive to prevent attacks based on hash collisions. (CVE-2011-4885) * Fixed bug #60150 (Integer overflow during the parsing of invalid exif header). (CVE-2011-4566) signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: wikicaptcha on GitHub
I spoke to some people at the Internet Archive about the ReCaptcha situation, and learned something interesting. Apparently, although IA provided a large dataset to ReCaptcha, they never got any data back, and then after the Google acquisition, they got shut out completely. I highly recommend we get IA involved if at all possible - it sounds like they have a data set they could provide us (identical to the one they provided ReCaptcha), or at least know exactly how to generate one. We could, you know, ACTUALLY provide them with the results and be good open content citizens. - Trevor On Wed, Jan 11, 2012 at 9:27 AM, Cristian Consonni kikkocrist...@gmail.comwrote: 2012/1/11 David Gerard dger...@gmail.com: On 11 January 2012 17:19, Cristian Consonni kikkocrist...@gmail.com wrote: We could also decorate our captcha with this captcha helps transcribing BOOK TITLE + link. Hah, use it for editor recruitment! That was the point, indeed. Cristian ___ 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
Re: [Wikitech-l] should we keep $wgDeprecationWhitelist
My inclination is to get rid of the feature for pretty much the reason you mentioned. In any case, is the point to avoid notices getting added to HTML for wikis with certain extensions? I don't know why a production site would be set to spew notices. Either error log settings or $wgDevelopmentWarnings can handle this. If it's to avoid them in the log, again, $wgDevelopmentWarnings works. IMO, the notices are most useful for core extension developers testing their code (who deliberately let all warnings get spewed out). If the dev has time to work other extensions, and has the affected one enabled on the same test wikis that have other extensions being worked on, *then* it might be useful to hide certain warnings. However, it seems better to just delay the deprecation in core a cycle. The use case for the new global just seems too marginal and it seems pretty awkward and hacky. -- View this message in context: http://wikimedia.7.n6.nabble.com/should-we-keep-wgDeprecationWhitelist-tp3600656p3600788.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: wikicaptcha on GitHub
On 11 January 2012 19:03, Trevor Parscal tpars...@wikimedia.org wrote: Apparently, although IA provided a large dataset to ReCaptcha, they never got any data back, and then after the Google acquisition, they got shut out completely. I highly recommend we get IA involved if at all possible - it sounds like they have a data set they could provide us (identical to the one they provided ReCaptcha), or at least know exactly how to generate one. We could, you know, ACTUALLY provide them with the results and be good open content citizens. I wonder if Google will try bringing patent claims against a reimplementation of reCaptcha. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: wikicaptcha on GitHub
We have a lawyer that can help determine that. It's not obvious to me (or you apparently) so I guess we should get one involved. - Trevor On Wed, Jan 11, 2012 at 11:07 AM, David Gerard dger...@gmail.com wrote: On 11 January 2012 19:03, Trevor Parscal tpars...@wikimedia.org wrote: Apparently, although IA provided a large dataset to ReCaptcha, they never got any data back, and then after the Google acquisition, they got shut out completely. I highly recommend we get IA involved if at all possible - it sounds like they have a data set they could provide us (identical to the one they provided ReCaptcha), or at least know exactly how to generate one. We could, you know, ACTUALLY provide them with the results and be good open content citizens. I wonder if Google will try bringing patent claims against a reimplementation of reCaptcha. - d. ___ 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
Re: [Wikitech-l] should we keep $wgDeprecationWhitelist
On 11 January 2012 19:04, Aaron Schulz aschulz4...@gmail.com wrote: My inclination is to get rid of the feature for pretty much the reason you mentioned. In any case, is the point to avoid notices getting added to HTML for wikis with certain extensions? I don't know why a production site would be set to spew notices. Either error log settings or $wgDevelopmentWarnings can handle this. If it's to avoid them in the log, again, $wgDevelopmentWarnings works. IMO, the notices are most useful for core extension developers testing their code (who deliberately let all warnings get spewed out). If the dev has time to work other extensions, and has the affected one enabled on the same test wikis that have other extensions being worked on, *then* it might be useful to hide certain warnings. However, it seems better to just delay the deprecation in core a cycle. The use case for the new global just seems too marginal and it seems pretty awkward and hacky. I generally agree that this is not a good addition. If a developer suppresses warnings, he will then proceed to forget about the warning that was suppressed, that's just a simple fact of life. Then the whole benefit of the warning system is negated; the developer is just as likely to update their version and find that things break as if they had turned off deprecation warnings altogether. Rather, if a developer upgrades from 1.16 to 1.17 and notices a new interface and a @deprecated warning on the old one, concludes that he cannot fix it until 1.19 is released and he can drop support for 1.16, then upgrades to 1.18 and starts getting warnings, he should hack core to remove the wfDeprecated statement from the old interface. Then when he upgrades to 1.19, the probably-now-forgotten hack is overwritten and the warnings reappear, reminding him that he should now start seriously thinking about reworking the extension code. He can then update, test and release a 1.19-compatible version of the extension before the core function itself is removed in 1.20. --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] should we keep $wgDeprecationWhitelist
Hey, However, it seems better to just delay the deprecation in core a cycle. The policy of half deprecating things, by placing a detraction notice in the docs but not have a call to wfDeprecated is very flawed. Either you deprecated something or you don't. And if you do, you make sure people that want to be able to know they are using a deprecated function as soon as they do are able to. This is what makes it useful for extension developers. So, for everyone with $wgDeperectionReleaseLimit set to false, ie everyone that gets all deprecation notices, it's very useful to have a way to ignore a certain deprecated interface they can not take care of for some reason, rather then being forced to turn off deprecation warnings for everything. Either error log settings or $wgDevelopmentWarnings can handle this. If it's to avoid them in the log, again, $wgDevelopmentWarnings works. So as I already mentioned, this would force developers from turning off the whole thing. IMO, the notices are most useful for core extension developers testing their code Well, obviously, this is what this setting is for. It is NOT to hide warnings on production wikis. Yes, I read what you wrote, I just happen to disagree with you. If a bunch of extension developers maintaining extensions with wide compatibility requirements agree that this is not useful, then I'll revert myself. What I've seen so far are core developers apparently not being able to put themselves in the shoes of extension developers. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r108647]: Revision status changed
Reedy changed the status of MediaWiki.r108647 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108647 Old status: new New status: ok Commit summary for MediaWiki.r108647: Fix syntax error in r108645. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108638]: Revision status changed
Reedy changed the status of MediaWiki.r108638 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108638 Old status: new New status: ok Commit summary for MediaWiki.r108638: removed leftover debug cruft ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108649]: Revision status changed
Reedy changed the status of MediaWiki.r108649 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108649 Old status: new New status: ok Commit summary for MediaWiki.r108649: Remove double space and trailing whitespace. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108538]: Revision status changed
Preilly changed the status of MediaWiki.r108538 to new URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108538 Old status: fixme New status: new Commit summary for MediaWiki.r108538: do not call the addHTML method unless needed also check carrier header correctly ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r108651]: Revision status changed
Nikerabbit changed the status of MediaWiki.r108651 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108651 Old status: new New status: ok Commit summary for MediaWiki.r108651: fix for r108538 c29341 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
