[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 z...@mzmcbride.com 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
[MediaWiki-CodeReview] [MediaWiki r91714]: Revision status changed
User Bryan changed the status of MediaWiki.r91714. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91714#c0 Commit summary: revert r91673 : lost of history ___ 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 DieBuche posted a comment on MediaWiki.r91673. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91673#c19339 Commit summary: Moving cologneblue.css and nostalgia.css into their own folder Comment: How can I see whether I moved something correctly? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] thumbnail generation for Extension:OggHandler
Hi! What's the proper way of thumbnail generation for Ogg media handler, so it will work like at commons? First, I've downloaded and compiled latest ffmpeg version (from git://git.videolan.org/ffmpeg.git) using the following configure options: ./configure --prefix=/usr --disable-ffserver --disable-encoder=vorbis --enable-libvorbis The prefix is usual for CentOS layout (which I have at hosting) and best options for vorbis were suggested in this article: http://xiphmont.livejournal.com/51160.html I've downloaded Apollo_15_launch.ogg from commons then uploaded to my wiki to check Ogg handler. The file was uploaded fine, however the thumbnail is broken - there are few squares at gray field displayed instead of rocket still image. In Extension:OggHandler folder I found ffmpeg-bugfix.diff. However there is no libavformat/ogg2.c in current version of ffmpeg. Even, I found the function ogg_get_length () in another source file, however the code was changed and I am not sure that manual comparsion and applying is right way. It seems that the patch is suitable for ffmpeg version developed back in 2007 but I was unable to find original sources to successfully apply the patch. I was unable to find ffmpeg in Wikimedia svn repository. Is it there? Then, I've tried svn co https://oggvideotools.svn.sourceforge.net/svnroot/oggvideotools oggvideotools but I am upable to compile neither trunk nor branches/dev/timstarling version, it bails out with the following error: -- ERROR: Theora encoder library NOT found -- ERROR: Theora decoder library NOT found -- ERROR: Vorbis library NOT found -- ERROR: Vorbis encoder library NOT found -- ogg library found -- GD library and header found CMake Error at CMakeLists.txt:113 (MESSAGE): I have the following packages installed: libvorbis-1.1.2-3.el5_4.4 libvorbis-devel-1.1.2-3.el5_4.4 libogg-1.1.3-3.el5 libogg-devel-1.1.3-3.el5 libtheora-devel-1.0alpha7-1 libtheora-1.0alpha7-1 ffmpeg compiles just fine (with yasm from alternate repo, of course). But there is no libtheoradec, libtheoraenc, libvorbisenc neither in main CentOS repository nor in aliernative http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/ However it seems these is libtheoraenc.c in ffmpeg; what is the best source of these libraries? It seems that there is no chance to find proper rpm's for CentOS and one need to compile these from sources? Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91628]: Revision status changed
User ^demon changed the status of MediaWiki.r91628. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91628#c0 Commit summary: Followup r91627 svn:eol-style native Remove ? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91721]: New comment added
User ^demon posted a comment on MediaWiki.r91721. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91721#c19340 Commit summary: Backport jQuery UI CSS fix for weird Webkit reflow bug. See https://github.com/jquery/jquery-ui/commit/a090faa833cf5b40105bb4aa74bca7ac39366fe9/ Comment: This appears to do a lot more than just add that one CSS line, but I'll defer to the judgement of someone like Roan or Krinkle. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91721]: Revision status changed
User DieBuche changed the status of MediaWiki.r91721. Old Status: new New Status: reverted Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91721#c0 Commit summary: Backport jQuery UI CSS fix for weird Webkit reflow bug. See https://github.com/jquery/jquery-ui/commit/a090faa833cf5b40105bb4aa74bca7ac39366fe9/ ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91721]: New comment added, and revision status changed
User ^demon changed the status of MediaWiki.r91721. Old Status: reverted New Status: new User ^demon also posted a comment on MediaWiki.r91721. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91721#c19341 Commit summary: Backport jQuery UI CSS fix for weird Webkit reflow bug. See https://github.com/jquery/jquery-ui/commit/a090faa833cf5b40105bb4aa74bca7ac39366fe9/ Comment: Strike that, revert came in before I pressed save. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91721]: Revision status changed
User ^demon changed the status of MediaWiki.r91721. Old Status: new New Status: reverted Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91721#c0 Commit summary: Backport jQuery UI CSS fix for weird Webkit reflow bug. See https://github.com/jquery/jquery-ui/commit/a090faa833cf5b40105bb4aa74bca7ac39366fe9/ ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91722]: Revision status changed
User ^demon changed the status of MediaWiki.r91722. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91722#c0 Commit summary: Revert botched commit r91721 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91263]: New comment added, and revision status changed
User ^demon changed the status of MediaWiki.r91263. Old Status: ok New Status: reverted User ^demon also posted a comment on MediaWiki.r91263. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91263#c19342 Commit summary: Fix for Bug #29628 - scriptpath Option of maintenance/install.php is ignored The Script Path Option (--scriptpath) of maintenance/install.php is silently ignored if there is $_SERVER['SCRIPT_NAME'] set. Apply patch from Tobias Müller. Comment: Reverted in r ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91730]: New comment added
User DieBuche posted a comment on MediaWiki.r91730. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91730#c19343 Commit summary: demon is right, Mac is much more common nowadays. r91646 Comment: Graph : http://www.google.com/trends?q=mac+computer%2C+macintosh+computerctab=0geo=alldate=allsort=0 :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91646]: New comment added
User DieBuche posted a comment on MediaWiki.r91646. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91646#c19344 Commit summary: Rephrasing msg clearyourcache per Bug 27550 : Adding Chrome, moving up IE, making it a bulltetd list. Thanks Amir E. Aharoni Comment: Changed in r91730 . http://www.google.com/trends?q=mac+computer%2C+macintosh+computerctab=0geo=alldate=allsort=0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91732]: New comment added
User Reedy posted a comment on MediaWiki.r91732. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91732#c19346 Commit summary: Create a new RequestContext to use its OutputPage and Skin members instead of messing with global ones Comment: Should createContext be caching? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91732]: New comment added
User IAlex posted a comment on MediaWiki.r91732. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91732#c19347 Commit summary: Create a new RequestContext to use its OutputPage and Skin members instead of messing with global ones Comment: In my opinion it should not, otherwise it could mess between different modules (in internal calls, etc.) The module using it need to store it somewhere if it has to. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91733]: Revision status changed
User Preilly changed the status of MediaWiki.r91733. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91733#c0 Commit summary: Fix r91706 (bug 28147): removing the as it suggests you're logged in to *all* wikis, which is not the case (see bug 14407) ___ 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 Krinkle changed the status of MediaWiki.r91642. Old Status: fixme New Status: reverted User Krinkle also posted a comment on MediaWiki.r91642. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91642#c19348 Commit summary: Bug #29755: Apply patch from Vitaliy Filippov so that MW's HTTP client respects no_proxy env setting Comment: Reopening bug 29755, patch wasn't reviewed yet. (or rather, it wasn't a patch/diff at all). I think it was a good experience to trigger code review by committing it (which may have been a coincidence), but I don't think it's something that should be a acceptable way of getting code review. It will only stress developers into maintaining trunk. In a time where pre-commit review is being considered (perhaps even github-like forks and merges, there even are github projects of which the history solely consists of merges! that result from pull-requests that have been reviewed first), this doesn't look good. It's probably easy to turn this into a patch and make it happy with the conventions but to keep the patch simple I've reverted it for now. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91738]: Revision status changed
User Bryan changed the status of MediaWiki.r91738. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91738#c0 Commit summary: Reverting r91642 per CR and pending review need-patch/patch in bug 29755 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] thumbnail generation for Extension:OggHandler
I recommend using the static binaries hosted on firefogg or if you want to compile it your self using the build tools provided there: http://firefogg.org/nightly/ Also I would suggest you take a look at TimedMediahandler as an alternative to oggHandler it has a lot more features such as WebM, timed text, and transcoding support. http://www.mediawiki.org/wiki/Extension:TimedMediaHandler A live install is on prototype if you want to play around with it: http://prototype.wikimedia.org/tmh/ If you run into any issue, please report them on the bug tracker or directly to me. https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensionscomponent=TimedMediaHandler peace, --michael On 07/08/2011 04:18 AM, Dmitriy Sintsov wrote: Hi! What's the proper way of thumbnail generation for Ogg media handler, so it will work like at commons? First, I've downloaded and compiled latest ffmpeg version (from git://git.videolan.org/ffmpeg.git) using the following configure options: ./configure --prefix=/usr --disable-ffserver --disable-encoder=vorbis --enable-libvorbis The prefix is usual for CentOS layout (which I have at hosting) and best options for vorbis were suggested in this article: http://xiphmont.livejournal.com/51160.html I've downloaded Apollo_15_launch.ogg from commons then uploaded to my wiki to check Ogg handler. The file was uploaded fine, however the thumbnail is broken - there are few squares at gray field displayed instead of rocket still image. In Extension:OggHandler folder I found ffmpeg-bugfix.diff. However there is no libavformat/ogg2.c in current version of ffmpeg. Even, I found the function ogg_get_length () in another source file, however the code was changed and I am not sure that manual comparsion and applying is right way. It seems that the patch is suitable for ffmpeg version developed back in 2007 but I was unable to find original sources to successfully apply the patch. I was unable to find ffmpeg in Wikimedia svn repository. Is it there? Then, I've tried svn co https://oggvideotools.svn.sourceforge.net/svnroot/oggvideotools oggvideotools but I am upable to compile neither trunk nor branches/dev/timstarling version, it bails out with the following error: -- ERROR: Theora encoder library NOT found -- ERROR: Theora decoder library NOT found -- ERROR: Vorbis library NOT found -- ERROR: Vorbis encoder library NOT found -- ogg library found -- GD library and header found CMake Error at CMakeLists.txt:113 (MESSAGE): I have the following packages installed: libvorbis-1.1.2-3.el5_4.4 libvorbis-devel-1.1.2-3.el5_4.4 libogg-1.1.3-3.el5 libogg-devel-1.1.3-3.el5 libtheora-devel-1.0alpha7-1 libtheora-1.0alpha7-1 ffmpeg compiles just fine (with yasm from alternate repo, of course). But there is no libtheoradec, libtheoraenc, libvorbisenc neither in main CentOS repository nor in aliernative http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/ However it seems these is libtheoraenc.c in ffmpeg; what is the best source of these libraries? It seems that there is no chance to find proper rpm's for CentOS and one need to compile these from sources? Dmitriy ___ 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 r91673]: New comment added
User DieBuche posted a comment on MediaWiki.r91673. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91673#c19349 Commit summary: Moving cologneblue.css and nostalgia.css into their own folder Comment: I figured it out myself: It's moved correctly if svn blame is still working on the new file.. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91743]: Revision status changed
User ^demon changed the status of MediaWiki.r91743. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91743#c0 Commit summary: Removed some error suppression operators ___ 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 Aaron Schulz posted a comment on MediaWiki.r88054. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88054#c19350 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: BeforeParserFetchFileAndTitle in Parser.php. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87531]: New comment added, and revision status changed
User IAlex changed the status of MediaWiki.r87531. Old Status: ok New Status: fixme User IAlex also posted a comment on MediaWiki.r87531. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87531#c19351 Commit summary: create wikitweet extension in trunk Comment: Some comments : * [[Manual:$wgMessageCache|$wgMessageCache]] doesn't exist anymore, it was replaced by codeMessageCache::singleton()/code, in the same time codeMessageCache::addMessages()/code and codeMessageCache::addMessagesByLang()/code were also removed. You will need to use [[Manual:$wgExtensionMessagesFiles|$wgExtensionMessagesFiles]] properly. * Don't use an extension function to register parser hooks, but the [[Manual:Hooks/ParserFirstCallInit|ParserFirstCallInit]] hook * tweetmail.php seems to duplication code from UserMailer.php, can't the core version of that code be used instead? * It would be much better to put the functions in gettweets.php, updatetweet.php, subscribe.php and deletetweet.php in classes so that the files can be automatically loaded instead of having to do the coderequire_once()/code manually (see [[Manual:$wgAutoloadClasses]]) * We have an implicit convention that files starting with a lowercase letter are maintenance scripts (to be executed from a shell) and not include files * Your enconding is broken, remember that we utf-8, and only utf-8. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91651]: New comment added
User SPQRobin posted a comment on MediaWiki.r91651. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91651#c19352 Commit summary: (bug 27410) The tag filter on a history page should be within a label element. Patch by The Evil IP Address. Also remove inclusion protection for the 800th time: if a file only has classes, you don't need to do this :) Comment: This escapes the wikilink (in the message), so you see a href=/mw/index.php/Special:Tags title=Special:TagsLabelfilter/a ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91751]: Revision status changed
User Bryan changed the status of MediaWiki.r91751. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91751#c0 Commit summary: Partial revert of r91746 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91746]: Revision status changed
User Bryan changed the status of MediaWiki.r91746. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91746#c0 Commit summary: Apply slightly modified patch of https://bugzilla.wikimedia.org/show_bug.cgi?id=28613#c35 to 1.17wmf1 Testing thumbnail purging issues ___ 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 MarkAHershberger posted a comment on MediaWiki.r91668. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91668#c19353 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 agree that there is probably something that should be fixed in LQT so that it checks to make sure there is actually an email address to send to. In fact this doesn't solve the problem. Emails can still be sent w/o an actual address. ___ 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#c19354 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 the issue is more in where-ever we do verifications that the email is authenticated. Really its not LQT's job to do that, but should use the same code as special:emailuser/watchlist notifications/etc uses. (I'm assuming said code exists somewhere, I don't know enough about email stuff to say if that's actually the case or not) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91754]: New comment added
User Reedy posted a comment on MediaWiki.r91754. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91754#c19355 Commit summary: redoing r91673 . I need to commit in two steps to preserve the file's history Comment: You've lost the history And it can be done in 1 commit ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91754]: New comment added
User Reedy posted a comment on MediaWiki.r91754. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91754#c19356 Commit summary: redoing r91673 . I need to commit in two steps to preserve the file's history Comment: Ignore the first bit, viewvc seemed to being fail But it could've been done in one commit ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91755]: Revision status changed
User Krinkle changed the status of MediaWiki.r91755. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91755#c0 Commit summary: redoing r91673 . Second step: Actually moving the files ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91755]: New comment added
User Hashar posted a comment on MediaWiki.r91755. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91755#c19357 Commit summary: redoing r91673 . Second step: Actually moving the files Comment: Congratulations on the file move :-) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91756]: New comment added
User Hashar posted a comment on MediaWiki.r91756. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91756#c19358 Commit summary: Bug 26470 : Add checkered background image for transparent images on hover Comment: Using :hover is a smart idea! You might want to add an entry in RELEASE-NOTES. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91730]: Revision status changed
User Hashar changed the status of MediaWiki.r91730. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91730#c0 Commit summary: demon is right, Mac is much more common nowadays. r91646 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r263]: New comment added
User Awjrichards posted a comment on Wikimedia.r263.
Full URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/263#c19359
Commit summary:
Card #189
Adds in some basic error switching on inport failure.
Comment:
In
trunk/fundraising-civicrm/sites/all/modules/queue2civicrm/queue2civicrm_common.inc:
pre
+ foreach($severity as $rank=$code){
+ if(array_key_exists($code, $error)){
+ $top_code = $code;
+ break;
+ }
+ }
/pre
It doesn't look like code$rank/code is being used. You might just change
this to:
pre
foreach( $severity as $code ) {}
/pre
for readability/clarity.
Another stylistic point, 99% of the logic in
code_queue2civicrm_get_seriousest_new_drush_error()/code lives inside of an
if() statement. Also for clarity/readability, use early returns, so instead
of:
pre
+function _queue2civicrm_get_seriousest_new_drush_error(){ //totally a word.
+ $error = _queue2civicrm_get_new_drush_errors();
+
+ $top_error = false;
+ if (!empty($error)){ //pull the Top of Bad.
+ $severity = array(
+ 'CIVI_CONFIG',
+ 'STOMP_BAD_CONNECTION',
+ 'CIVI_REQ_FIELD',
+ 'IMPORT_CONTACT',
+ 'IMPORT_CONTRIB',
+ 'IMPORT_TAG',
+ );
...
/pre
maybe try:
pre
function _queue2civicrm_get_seriousest_new_drush_error(){ //totally a word.
$error = _queue2civicrm_get_new_drush_errors();
if ( empty( $error )) {
return false;
}
$severity = array(
/pre
In
trunk/fundraising-civicrm/sites/all/modules/queue2civicrm/queue2civicrm.module:
pre
try {
+ _queue2civicrm_get_new_drush_errors(); //redefine new before
we move on.
if (queue2civicrm_import($msg)){
/pre
What is the reason for running _queue2civicrm_get_new_drush_errors() here?
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r263]: Revision status changed
User Awjrichards changed the status of Wikimedia.r263. Old Status: new New Status: fixme Full URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/263#c0 Commit summary: Card #189 Adds in some basic error switching on inport failure. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r264]: New comment added, and revision status changed
User Awjrichards changed the status of Wikimedia.r264.
Old Status: new
New Status: ok
User Awjrichards also posted a comment on Wikimedia.r264.
Full URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/264#c19360
Commit summary:
followup r263
Cleaned up some of the logic in the mechanism that pulls the top error, and
wrote a test to make sure it was doing the right thing.
Comment:
A I already miss this:
pre
-function _queue2civicrm_get_seriousest_new_drush_error(){ //totally a word.
+function _queue2civicrm_get_top_new_drush_error(){
/pre
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91756]: New comment added
User Edokter posted a comment on MediaWiki.r91756. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91756#c19361 Commit summary: Bug 26470 : Add checkered background image for transparent images on hover Comment: Not the history table...! Just the main image please. The history should show tranparency regardles. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r265]: New comment added, and revision status changed
User Awjrichards changed the status of Wikimedia.r265. Old Status: new New Status: ok User Awjrichards also posted a comment on Wikimedia.r265. Full URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/265#c19362 Commit summary: Card #189 Adds the email notification mechanism for failed processing. Comment: trunk/fundraising-civicrm/sites/all/modules/queue2civicrm/tests/queue2civicrm.test: Can we make the test emails configurable? Unless you want to get a buttload of random emails :p ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91756]: New comment added
User Bawolff posted a comment on MediaWiki.r91756. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91756#c19363 Commit summary: Bug 26470 : Add checkered background image for transparent images on hover Comment: I don't necessarily agree with that (but really its a bikeshed) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r263]: New comment added
User Khorn (WMF) posted a comment on Wikimedia.r263. Full URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/263#c19364 Commit summary: Card #189 Adds in some basic error switching on inport failure. Comment: Made the changes to _queue2civicrm_get_top_new_drush_error(). To answer the last question: I call _queue2civicrm_get_new_drush_errors() there, to update the static variable of old drush errors in that function before we dive in to potentially get new ones. I could call the same function with a differently-named wrapper function for clarity's sake, but the only thing it would do is call _queue2civicrm_get_new_drush_errors(). I have to do this here, because old errors might not necessarily have already been handled unless they were severe enough to cause their import process to return false (more mild errors would, however, cause the main process to exit abnormally at the end of it all, so Hudson could pick them up. In other words: Less severe errors aren't just being swallowed, but they might not interrupt the loop we're in enough to be relevant in the context of the item we're about to handle. Of course, this is all a moot point if all the error codes are correctly placed in _queue2civicrm_get_top_new_drush_error(), in the $severity() array... ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91756]: New comment added
User Edokter posted a comment on MediaWiki.r91756. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91756#c19365 Commit summary: Bug 26470 : Add checkered background image for transparent images on hover Comment: A I've stated in the bug, if you have to hover over everyone of them, it is going to be very annoying (they're thumbs anyway). The history is to check for errors in one lookover. So history (and possibly images in categories) should have transparency turned on. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91760]: Revision status changed
User Hashar changed the status of MediaWiki.r91760. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91760#c0 Commit summary: Selfrevert r91759. Messed up working-copy ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91756]: New comment added, and revision status changed
User Krinkle changed the status of MediaWiki.r91756. Old Status: new New Status: reverted User Krinkle also posted a comment on MediaWiki.r91756. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91756#c19366 Commit summary: Bug 26470 : Add checkered background image for transparent images on hover Comment: I'm tempted to repond to the situation Edokter sketched, but it's quite clear that there are a few issues to figure out before doing anything. Suggesting we elaborate further on BugZilla, where clearly the discussion wasn't over yet. Reverted in r91761. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91759]: Revision status changed
User Hashar changed the status of MediaWiki.r91759. Old Status: new New Status: reverted Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91759#c0 Commit summary: Reverting r91756 per CR and bug 26470 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r269]: Revision status changed
User Awjrichards changed the status of Wikimedia.r269. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/269#c0 Commit summary: followup r263 Stylistic changes to _queue2civicrm_get_top_new_drush_error() ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r263]: Revision status changed
User Awjrichards changed the status of Wikimedia.r263. Old Status: fixme New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/263#c0 Commit summary: Card #189 Adds in some basic error switching on inport failure. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91761]: Revision status changed
User Hashar changed the status of MediaWiki.r91761. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91761#c0 Commit summary: Reverting r91756 per CR and bug 26470 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88425]: New comment added
User Hashar posted a comment on MediaWiki.r88425. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88425#c19367 Commit summary: Revert r88399 (delete fuzz-tester). Apparently people use it ;-) Comment: removing tag 'hasharissilly' to have less tags showing in the cloud tag. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91762]: New comment added
User Hashar posted a comment on MediaWiki.r91762. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91762#c19368 Commit summary: Undo browser defaults (underline/strike) for the del and ins DairikiDiff inserts. Fixes bug 29779 Comment: Does it need a backport to 1.18/1.17? The bug report was mentioning 1.17 (I have updated it to 1.19-svn since). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91762]: New comment added
User Krinkle posted a comment on MediaWiki.r91762. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91762#c19369 Commit summary: Undo browser defaults (underline/strike) for the del and ins DairikiDiff inserts. Fixes bug 29779 Comment: Yes. Sorry forgot to tag. note there is no need to merge to 1.17wmf1 as WMF uses a different diff engine. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] “Easy” Bug Triage meeting notes
On 07/08/2011 02:20 PM, Mark A. Hershberger wrote: This past Wednesday, we had our second IRC triage. The focus was on triaging bugs marked “easy”, verifying that they were still bugs and making sure they were actually something a new coder could do. This meant we had a larger number of bugs to cover. I had planned only 2 minutes per bug in order to get through all of them in an hour which caused problems. This short time limit created some problems which means I'll have to be careful to restrict the number of bugs in the future, or tell people the time for the triage will be longer than one hour. Still, despite the problems, hosting the triage in IRC meant that some developers interested in MediaWiki that Sumana invited were able to watch and volunteer developers were able able to participate. Mark: Thanks, as always, for running this triage. I have now added the relevant bugs to http://www.mediawiki.org/wiki/Annoying_Little_Bug which you should feel free to hand out to developers interested in writing their first MediaWiki patch. -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91765]: Revision status changed
User Reedy changed the status of MediaWiki.r91765. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91765#c0 Commit summary: Wow major typo, r91763 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91687]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91687. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91687#c0 Commit summary: Fix r91685: add space at the right place. (Also removing unused variable in protectedtitles.) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r265]: New comment added
User Khorn (WMF) posted a comment on Wikimedia.r265. Full URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/265#c19370 Commit summary: Card #189 Adds the email notification mechanism for failed processing. Comment: Oooh, yes. Good point. I have addressed this with a new module for WMF test variables. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91770]: New comment added
User Krinkle posted a comment on MediaWiki.r91770. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91770#c19371 Commit summary: Translate the block expiry date I wonder why this hasn't been done yet... Comment: Would this change affect the output in the IRC channels ? The block duration noted there must be in English for bots depending on them (there are many!). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91770]: New comment added
User Krinkle posted a comment on MediaWiki.r91770. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91770#c19372 Commit summary: Translate the block expiry date I wonder why this hasn't been done yet... Comment: ie. irc.wikimedia.org/#foo.bar ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] The non-coder friendly weekend sprint: Check pre-1.17 bugs
This week, Sumana said she had some people who were interested in looking at old bugs to see if they were still reproducible under 1.17. I decided to steal this idea for a great weekend sprint that even people who are not developers could take part in: Help me look at these bug reports and see if the problems they describe are still reproducible or if the problem has been fixed. If you don't have a test wiki with 1.17 installed, then you can try to reproduce a lot of these on Wikipedia in your user sandbox. If you don't have one yet, you can use this link to load one: http://hexm.de/4w If you come across one that you don't know how to reproduce in your user sandbox or on your own wiki, then add the keyword “testme”. With that out of the way, there are plenty of bugs to test. Here are a few ways to find a good candidate for testing: * There are currently 616 bugs that are explicitly filed against pre-1.17 versions of MediaWiki: http://hexm.de/4e * If you modify the query to remove those bugs labeled “enhancement”, you'll end up with 345 bugs: http://hexm.de/4j * Some bugs just have “unspecified” as the version. There are 1747 MW that were created before 2011-06-22 (1.17's release date) with “unspecified” as the version number: http://hexm.de/4f * Again, if you remove the ones labeled “enhancement”, you come up with 526 bugs: http://hexm.de/4g You can do all sorts of things to reduce the list to nice bite-sized chunks. Here, for example are smaller lists of bugs marked “normal” or higher severity for each version of MW in bugzilla: 1.6.x (11 bugs) http://hexm.de/4k 1.7.x (5 bugs) http://hexm.de/4l 1.8.x (3 bugs) http://hexm.de/4m 1.9.x (14 bugs) http://hexm.de/4n 1.10.x (17 bugs) http://hexm.de/4o 1.11.x (23 bugs) http://hexm.de/4p 1.12.x (20 bugs) http://hexm.de/4q 1.13.x (21 bugs) http://hexm.de/4r 1.14.x (26 bugs) http://hexm.de/4s 1.15.x (42 bugs) http://hexm.de/4t All 1.16 versions (94 bugs) http://hexm.de/4v I'm fascinated by the jump from 26 bugs version 1.14 to 42 bugs in version 1.15 and then the big bounce to 94 bugs in 1.16 and think this is a good area to dig into. I'm interested in *why* that is there, whether it is because of more people checking, better reporting, or (hopefully not) worse solving. Of course, we still need people to look at the “testme” bugs, too: http://hexm.de/4i Finally, if you have followed the steps in the bug and can't reproduce it, please mark it “FIXED”. Comments are always helpful on the bugs, so leave one if you have a question or comment about the bug. Happy Testing! Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The non-coder friendly weekend sprint: Check pre-1.17 bugs
On Fri, Jul 8, 2011 at 7:47 PM, Mark A. Hershberger mhershber...@wikimedia.org wrote: I'm fascinated by the jump from 26 bugs version 1.14 to 42 bugs in version 1.15 and then the big bounce to 94 bugs in 1.16 and think this is a good area to dig into. I'm interested in *why* that is there, whether it is because of more people checking, better reporting, or (hopefully not) worse solving. If memory serves, we started to see an increase in the rate of bug reporting sometime around late 1.14 / early 1.15. I'd be interested to see the rate of incoming bugs graphed out, right now my evidence is largely empirical. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The non-coder friendly weekend sprint: Check pre-1.17 bugs
On 07/08/2011 07:47 PM, Mark A. Hershberger wrote: Finally, if you have followed the steps in the bug and can't reproduce it, please mark it “FIXED”. Actually, I think WORKSFORME is a better resolution here. FIXED implies that we know we've taken specific action to fix the bug. -- 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] The non-coder friendly weekend sprint: Check pre-1.17 bugs
On Fri, Jul 8, 2011 at 8:16 PM, Sumana Harihareswara suma...@wikimedia.org wrote: On 07/08/2011 07:47 PM, Mark A. Hershberger wrote: Finally, if you have followed the steps in the bug and can't reproduce it, please mark it “FIXED”. Actually, I think WORKSFORME is a better resolution here. FIXED implies that we know we've taken specific action to fix the bug. WORKSFORME or INVALID if we can prove it wasn't ever really a bug to begin with. FIXED definitely implies something was done to fix it, which won't be the case here. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91770]: New comment added
User SPQRobin posted a comment on MediaWiki.r91770. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91770#c19373 Commit summary: Translate the block expiry date I wonder why this hasn't been done yet... Comment: Good question. translateBlockExpiry() does translate the durations (week, month, ...) already, although I don't really know how, so it should work. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] all those zeros in tables in text brosers
I don't see why Wikipedia looks 99% fabulous in lynx and w3m, but blows it on such a simple thing like dates in tables, $ lynx -dump http://en.wikipedia.org/wiki/List_of_social_networking_websites Please note the list is not exhaustive, and is limited to notable, well-known sites. Name Description/Focus Date launched [12]Registered users Registration Global [13]Alexa^[14][1] Page ranking [15]Academia.edu Social networking site for academics/researchers 02008-09-01September 2008 002110211,000^[16][2] Open 9294009,294^[17][3] [18]Advogato [19]Free and [20]open source software developers 01999 1999 000135750013,575^[21][4] Open... Why can't they go that extra one percent and clean all those silly zeros out of their tables? Yes those stubborn text browser users should be denied extra features, but can't they at least be given something readable. Search engines would thank you too. Sure you can say not a MediaWiki problem, go contact the website, but if MediaWiki gave them the proper tools to make their templates, they wouldn't need to make such a mess. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] all those zeros in tables in text brosers
On Fri, Jul 8, 2011 at 11:23 PM, jida...@jidanni.org wrote: Sure you can say not a MediaWiki problem, go contact the website, but if MediaWiki gave them the proper tools to make their templates, they wouldn't need to make such a mess. What tools would you propose? -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] all those zeros in tables in text brosers
On 07/09/2011 06:25 AM, Chad wrote: On Fri, Jul 8, 2011 at 11:23 PM,jida...@jidanni.org wrote: Sure you can say not a MediaWiki problem, go contact the website, but if MediaWiki gave them the proper tools to make their templates, they wouldn't need to make such a mess. What tools would you propose? A smarter table sorter would help. (I believe those zeros come from sort keys generated by templates and hidden from most browsers by CSS.) As it happens, I believe we've just got (or are about to get?) one. But someone ought to go through http://en.wikipedia.org/wiki/Category:Sorting_templates and see just how many of them we can make unnecessary by smarter sorting. (It would also be nice to have some way to specify manual sort keys, in those cases where they really are needed, through some mechanism that doesn't involve CSS hacks.) -- Ilmari Karonen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91763]: Revision status changed
User Reedy changed the status of MediaWiki.r91763. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91763#c0 Commit summary: Use estimateRowCount() in CleanupTable rather than select count(*) which will take forer on tables like image or page. It's only used for estimating progress, so a little estimating is ok :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] all those zeros in tables in text brosers
C == Chad innocentkil...@gmail.com writes: C What tools would you propose? Can you find me one site on the Internet that butchers dates so 2011 becomes 02011 in text browsers? Yes I filed http://en.wikipedia.org/wiki/Template_talk:Dts#text_browsers . The next thing you know you'll be rendering it in hexadecimal. And the all those zer0s in the tables. My proposal is set the most important requirement to be that the rendered output be at least readable, if not the same, for all output devices and search engines. Then work backwards from that basic requirement to satisfy internal sorting requirements or what have you. ___ 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
C == Chad innocentkil...@gmail.com writes: C And span id=bla doesn't work why? And indeed, there it is, http://en.wikipedia.org/wiki/Help:HTML_in_wikitext#Using_.3Cspan.3E_as_a_link_target The first time I've ever been wrong about anything here. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcoming Ian Baker
Fire Performer? Aerial Acrobatics? Ho hum. Another boring hiring announcement. Why can't they write them like http://www.dreamhost.com/newsletter/0711.html#a1 ? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91752]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91752. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91752#c0 Commit summary: PHP Fatal error: Call to a member function isRedirect() on a non-object in /usr/local/apache/common-local/php-1.17/extensions/Collection/Collection.php on line 369 was seen on wmf cluster ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91753]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91753. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91753#c0 Commit summary: MFT r91752 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91715]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91715. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91715#c0 Commit summary: Follow-up r91657: missed this one ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91657]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91657. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91657#c0 Commit summary: * Don't use isset() to check only for null * Also pass the Title object in RequestContext::msg() ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91653]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91653. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91653#c0 Commit summary: Removed usage of error suppression operator ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91677]: New comment added
User Aaron Schulz posted a comment on MediaWiki.r91677. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91677#c19374 Commit summary: * Fixed comment * Wrap arround RequestContext::msg() instead of doing that all that stuff once more Comment: What about the codetitle( $this-getFullTitle() )/code bit? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91655]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91655. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91655#c0 Commit summary: Override IndexPager::getTitle() in ImageListPager, this is the only class subclassing TablePager that don't do that in core ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91575]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91575. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91575#c0 Commit summary: Move wfShowingResultsNum() back into SpecialSearch where it belongs. No need for a global function for something thats only used once in core or extensions ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
