[MediaWiki-CodeReview] [MediaWiki r85940]: Revision status changed
User MaxSem changed the status of MediaWiki.r85940. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85940#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85207]: New comment added
User Tim Starling posted a comment on MediaWiki.r85207. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85207#c15902 Comment: We use sigma (i.e. radius) 0.8 on Wikimedia now. We used sigma=0.4 with older versions of ImageMagick, because the matrix had some truncation applied to its elements which made it look like sigma=0.8. See bug 24857. Running convert -sharpen 0x0.8 with -debug Transform reveals that it uses a 7x7 matrix, not a 3x3 matrix. So there are two reasons why it wouldn't look as nice (as you complained on bug 25990 comment 14). Also, I think you should make the radius more easily configurable. You could generate the matrix from the radius and the width in MediaWiki. The formulas are easy enough, you can port them over from ImageMagick: pre normalize=0.0; j=(ssize_t) width/2; i=0; for (v=(-j); v = j; v++) { for (u=(-j); u = j; u++) { kernel[i]=(double) (-exp(-((double) u*u+v*v)/(2.0*MagickSigma* MagickSigma))/(2.0*MagickPI*MagickSigma*MagickSigma)); normalize+=kernel[i]; i++; } } kernel[i/2]=(double) ((-2.0)*normalize); /pre http://trac.imagemagick.org/browser/ImageMagick/trunk/magick/effect.c?rev=4188#L4351 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85931]: New comment added
User Krinkle posted a comment on MediaWiki.r85931. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85931#c15903 Comment: This file was not altered in r85928. Where does this come from ? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85929]: New comment added, and revision status changed
User Krinkle changed the status of MediaWiki.r85929. Old Status: new New Status: fixme User Krinkle also posted a comment on MediaWiki.r85929. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85929#c15904 Comment: After up'ing to this revision my local wiki doesn't do anything anymore, just display this: pre Fatal error: Class 'Action' not found in /trunk/phase3/includes/Wiki.php on line 474 /pre Test before commit ;-) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] ShortURL for Non Latin Mediawiki sites
* Srikanth Lakshmanan srik@gmail.com [Tue, 12 Apr 2011 22:29:33 +0530]: Hi all, Sharing of URLs of non latin wiki's werent really easy and when copy pasting we get the unicode numerals in the URL like http://ta.wikipedia.org/wiki/%E0%AE%B5%E0%AE%BF%E0%AE%95%E0%AF%8D%E0%AE%95%E0%AE%BF%E0%AE%AA%E0%AF%8D%E0%AE%AA%E0%AF%80%E0%AE%9F%E0%AE%BF%E0%AE%AF%E0%AE%BE:%E0%AE%86%E0%AE%B2%E0%AE%AE%E0%AE%B0%E0%AE%A4%E0%AF%8D%E0%AE%A4%E0%AE%9F%E0%AE%BF en:User:Mountain had come up with a shortify project[1] and thanks to Yuvipanda its now live on Tamil Wikipedia. All pages have a link on the right side of article title. http://tawp.in/r/262 is the same link and is being displayed there. The feedback from the community is to have this hosted by Wikimedia itself as it would be more reliable than individual running it. So there came the idea of a mediawiki extension and hence Shorturl extension[2] was born by some really quick work by Yuvipanda.Its live here[3].(See the toolbox for short URL) While this may be a small thing, it does help non latin wiki's a lot.Having it in the extension form is more reliable even though the URL length goes up, but still its worthy.The URL length can be shortened with mod_rewrite rules on. I would ideally like this to be used across non latin wikimedia properties as it helps these projects(like echoed here[4]). Please let me know how to do this. Bugs on wikimedia bugzilla will do? Feedback appreciated. I wish the numerous http and mail clients as well as web engines were able to display such links urldecoded, like Firefox does. I've made such patch for MediaWiki https://bugzilla.wikimedia.org/show_bug.cgi?id=25934 However, phpbb didn't decode such links, IE6/7/8 not as well :-( A lots of software and web engines probably has to be updated to recognize the utf-8 URI's. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85929]: New comment added
User Happy-melon posted a comment on MediaWiki.r85929. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85929#c15905 Comment: This is a result of having multiple separate things going on in my working copy at the same time and trying to break up commits. The Action class exists in my working copy and so tests fine, but both sets of changes alter Wiki.php in different ways. I missed the AutoLoader entry from r85928 for the same reason. This was already fixed in r85931. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85929]: Revision status changed
User Happy-melon changed the status of MediaWiki.r85929. Old Status: fixme New Status: new Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85929#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85931]: New comment added
User Happy-melon posted a comment on MediaWiki.r85931. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85931#c15906 Comment: This was fixing r85929, not r85928. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85939]: New comment added, and revision status changed
User Happy-melon changed the status of MediaWiki.r85939. Old Status: new New Status: ok User Happy-melon also posted a comment on MediaWiki.r85939. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85939#c15907 Comment: Looks like we were all off form last night tt:D/tt ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85922]: New comment added
User DieBuche posted a comment on MediaWiki.r85922. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85922#c15908 Comment: Thanks! Strict fixed in r85941 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85922]: New comment added
User Raymond posted a comment on MediaWiki.r85922. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85922#c15909 Comment: Could you please create a page with a few examples of the new possibilities at Translatewiki? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85922]: New comment added
User DieBuche posted a comment on MediaWiki.r85922. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85922#c15910 Comment: It doesn't add any new syntax, but simply renders stuff like http://translatewiki.net/wiki/TablesSandbox semantically correct. (Headers are actually theads, etc.) This makes it possible to switch to a better tablesorting script in the future. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85922]: New comment added
User Raymond posted a comment on MediaWiki.r85922. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85922#c15911 Comment: Thanks for the example. I was confused by the proposal for new syntax of the bug reporter. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85922]: New comment added
User Bryan posted a comment on MediaWiki.r85922. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85922#c15912 Comment: Welcome to commit land! I have some advise for you, mostly related to code style. See also [[Manual:Coding conventions]]. You should follow code conventions for variables. Thus $lastSection instead of $last_section. Your variables should be more descriptive. Use $tableDescriptor rather than $t. Check your whitespace use: ttarray_pop( $a )/tt instead of ttarray_pop($a)/tt. You can use stylize.php to enfore this style. Function names should really indicate what it does: a function called ttprintTableHtml/tt is expected to print/echo something to the output. It does not do that, it makes a string containing the table html. It should thus be named build/create/makeTableHtml; choose your favorite. Personally I don't really like mixed key arrays, where numeric keys indicate data elements, and string keys indicate attributes/options. I'd rather use a nested array solution, like ttarray( 'attributes' = array( ... ), 'caption = '...', 'data' = array( $row1, $row2, ... ) )/tt. Then you can use foreach on $t['data'] which is much cleaner than ttfor ( $i = 0; isset( $t[i] ); $i++ )/tt. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85876]: New comment added
User Mormegil posted a comment on MediaWiki.r85876. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85876#c15913 Comment: The code using ''Emailnotarget'' is broken: Since codetarget/code is used only if code$par/code is not received, you are not able to override a bad username by submitting a corrected one, the ''original'' is still checked. Try going to e.g. [[translatewiki:Special:Emailuser/NonexistentUser]] and submitting a different valid username. You either need to change codeuserForm/code so that it submits to the special page without the optional username parameter, or invert the order when retrieving code$this-mTarget/code in codeexecute/code. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Call for UI bugs
This coming week, I'd like to focus on any User Interface bugs. One of the lessons I learned from this last triage, though, is that we want to keep the bug reports current. With the introduction of ResourceLoader, this shouldn't be any trouble, but I want to make it clear that I will remove bugs from triage that haven't seen any activity for over 6 months. To help with find bugs that I would consider prime candidates for triage, I've created two queries. The first (http://hexm.de/1y) will find unassigned, open bugs that have been filed against MediaWiki in the past 6 months. About 200 bugs show up. The second query (http://hexm.de/1z) will find open bugs against MediaWiki modules created in the past 6 months that are, by default, assigned to wikimedia.org email addresses — with those assigned to wikibugs removed. The idea behind this query is to find bugs on MediaWiki modules that the WMF Features team is responsible for. This query finds about 100 bugs. From this pile of 300 bugs, I need to find about 30 bugs for Monday's triage meeting. Since I expect the Features team from WMF to have a higher turnout at this meeting, I'm trying to find bugs that are relevant to their recent work — bugs that they can fix now. I'll be going through these lists myself and putting the keyword “triage” on bugs that I think should go into the meeting. But you can get involved, too, if you see a bug from those two lists that I haven't marked for triage and you think it should really be considered, feel free to put the keyword “triage” on it yourself. Next week, I'll publish the results of the triage and open a new call for bugs. Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85804]: New comment added
User Reedy posted a comment on MediaWiki.r85804. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85804#c15914 Comment: Please make sure you enable the PHP STRICT stuff when testing stuff. You caused a STRICT warning/error which was fixed in r85948 See [[Manual:How_to_debug]] source lang=php error_reporting(E_ALL | E_STRICT); ini_set(display_errors, 1); /source Thanks! ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Syntax-highlighting JS CSS code editor gadget embedding Ace
Very cool. Especially given the development trajectory of Ace to become the eclipse of web IDEs there will be a lot of interesting possibilities as we could develop our own mediaWiki centric plugins for the platform. I can't help but think about where this is ideally headed ;) A gitorius type system for easy branching with mediaWiki.org code review style tools, with in browser editing. With seemless workflows for going from per user developing and testing on the live site, to commits to your personal repository, to being reviewed and tested by other developers, to being enabled by interested users, to being enabled by default if so desired. A lot of these workflows could be prototyped without many complicated infrastructure improvements. Since this basic process is already happening in a round about way ... ( sometimes in a round about broken way ) A developer gadget could include a simple system for switching between local checkout of the scripts and support pushing a particular local copy live or in the case of the online Ace editor, bootstrapping a particular page with the state of your script ( using the draft extension concept ) so we don't have to save every edit when you want to test your code. We could specify a path structure within our existing svn to keep in sync with all gadgets and site scripts, then have our 'developer gadget' understand that path structure so you could seamlessly switch between the local and live gadget. ( I was manually doing something similar in my gadget development ). This could also help encourage gadget centralisation. We could then also link into the code review system for every site script and gadget with one click import of a particular version of the script ( ideally once the script has been seen by other developers ). Svn commits would not nessisarally be automatically be pushed to the wiki but edits to the wiki page would always be pushed to the svn. Or maybe a sign off in code review results in the push from svn to wiki, but would not want to slow down fixes getting pushed out. We would have to see what workflows work best for the community. mmm ... this would would probably work better with git :P ... but certainly is not a show stopper to experimentation in improving these workflows. peace, --michael On 04/12/2011 07:40 PM, Brion Vibber wrote: While pondering some directions for rapid prototyping of new UI stuff, I found myself lamenting the difficulty of editing JS and CSS code for user/site scripts and gadgets: * lots of little things to separately click and edit for gadgets * no syntax highlighting in the edit box * no indication of obvious syntax errors, leading to frequent edit-preview cycles (especially if you have to turn the gadget back off to edit successfully!) * no automatic indentation! * can't use the tab key Naturally, I thought it might be wise to start doing something about it. I've made a small gadget script which hooks into editing of JS and CSS pages, and embeds the ACE code editor (http://ace.ajax.org -- a component of the Cloud9 IDE, formerly Skywriter formerly Mozilla Bespin). This doesn't fix the usability issues in Special:Gadgets, but it's a heck of a lot more pleasant to edit the gadget's JS and CSS once you get there. :) The gadget is available on www.mediawiki.org on the 'Gadgets' tab of preferences. Note that I'm currently loading the ACE JavaScript from toolserver.org, so you may see a mixed-mode content warning if you're editing via secure.wikimedia.org. (Probably an easy fix.) Go try it out! http://www.mediawiki.org/wiki/MediaWiki:Gadget-CodeEditor.js IE 8 kind of explodes and I haven't had a chance to test IE9 yet, but it seems pretty consistently nice on current Firefox and Chrome and (barring some cut-n-paste troubles) Opera. I'd really love to be able to use more content-specific editing tools like this, and using Gadgets is a good way to make this sort of tool available for testing in a real environment -- especially once we devise some ways to share gadgets across all sites more easily. I'll be similarly Gadget-izing the SVG-Edit widget that I've previously done as an extension so folks can play with it while it's still experimental, but we'll want to integrate them better as time goes on. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85885]: Revision status changed
User MaxSem changed the status of MediaWiki.r85885. Old Status: fixme New Status: new Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85885#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] About to commit improved DB2 database support
On 13.04.2011, 8:03 Tim wrote: On 13/04/11 02:41, Max Semenik wrote: It's DB2-only fixes, nothing scary about backporting it. Historically, DBMS support patches have touched a lot of query building code, and have caused bugs for MySQL. We should decide whether we want to backport it when we see it. It was already committed at the time of my post. In this particular case, no common code is touched other than registering DB2 within the installer, so it's pretty safe. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85804]: New comment added
User P.Copp posted a comment on MediaWiki.r85804. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85804#c15915 Comment: No idea how I missed that one. Anyway, thanks for the fix! ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85207]: New comment added
User Bryan posted a comment on MediaWiki.r85207. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85207#c15916 Comment: Well, that is an interesting way to calculate a sharpening matrix. But I guess if it works for them it will work for us as well. For my own reference: mathK_{ij} = -\frac{1}{2\pi\sigma^2} e^{\frac{i^2+j^2}{2\sigma^2}};/math mathK_{00} = -2\sum\sum K_{ij}/math ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Call for UI bugs
In last week's triage meeting we tended to surface really, really old bugs that only surface under edge or corner cases. For example, I now am assigned bug #93 which deals with how behaves inside nowiki. This is the paradigmatic example of a corner case. This isn't preventing anyone from getting their work done in MediaWiki, unless they happened to be compiling a wiki of ASCII art. I took the bug just to learn more about the parser, really. Maybe the Bugmeister role is still being defined, but I think it would be most helpful if we used these sessions to catch bugs that were important, but for one reason or another fell through the cracks. Some suggested heuristics (not rules!!): - older than 1 month -- so we know it may have fallen off the radar - not older than 4 years -- so it hasn't been proven not to be that important - should be considered in rewrites already planned -- goal should be to turn them into test cases - seem to affect lots of pages / users / use cases - seem to affect less common use cases but in a severe way My example of a great bug to consider: there's a bug / misdesign with Resource Loader that makes it hard to use RTL languages on international sites like Commons. This was actively debated a few months ago but ended in a compromise that didn't work well for Commons. (https://bugzilla.wikimedia.org/show_bug.cgi?id=6100) On 4/13/11 7:07 AM, Mark A. Hershberger wrote: This coming week, I'd like to focus on any User Interface bugs. One of the lessons I learned from this last triage, though, is that we want to keep the bug reports current. With the introduction of ResourceLoader, this shouldn't be any trouble, but I want to make it clear that I will remove bugs from triage that haven't seen any activity for over 6 months. To help with find bugs that I would consider prime candidates for triage, I've created two queries. The first (http://hexm.de/1y) will find unassigned, open bugs that have been filed against MediaWiki in the past 6 months. About 200 bugs show up. The second query (http://hexm.de/1z) will find open bugs against MediaWiki modules created in the past 6 months that are, by default, assigned to wikimedia.org email addresses — with those assigned to wikibugs removed. The idea behind this query is to find bugs on MediaWiki modules that the WMF Features team is responsible for. This query finds about 100 bugs. From this pile of 300 bugs, I need to find about 30 bugs for Monday's triage meeting. Since I expect the Features team from WMF to have a higher turnout at this meeting, I'm trying to find bugs that are relevant to their recent work — bugs that they can fix now. I'll be going through these lists myself and putting the keyword “triage” on bugs that I think should go into the meeting. But you can get involved, too, if you see a bug from those two lists that I haven't marked for triage and you think it should really be considered, feel free to put the keyword “triage” on it yourself. Next week, I'll publish the results of the triage and open a new call for bugs. Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Neil Kandalgaonkar |) ne...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85959]: Revision status changed
User Reedy changed the status of MediaWiki.r85959. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85959#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85885]: New comment added
User MaxSem posted a comment on MediaWiki.r85885. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85885#c15917 Comment: The message There must be a tablespace with at least 32k of pagesize looks like it needs some tweaks. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85890]: Revision status changed
User MaxSem changed the status of MediaWiki.r85890. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85890#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Call for UI bugs
Neil Kandalgaonkar ne...@wikimedia.org writes: Maybe the Bugmeister role is still being defined, but I think it would be most helpful if we used these sessions to catch bugs that were important, but for one reason or another fell through the cracks. Neil, Thanks for your comments and suggestions. I *am* still figuring this out; the role of Bugmeister is a new one for me. That said, I want to make sure you and other developers get something useful from the triage meetings. At the same time, I want to make sure we aren't ignoring problems that continue to cause people pain. Still, new pain tends to aggravate more than old, known pain, so your point about dealing with newer bugs is a good one, and it is one that I've already tried to include in my preparation for next week's triage. Thanks again for your feedback, Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85961]: Revision status changed
User Catrope changed the status of MediaWiki.r85961. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85961#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Syntax-highlighting JS CSS code editor gadget embedding Ace
On Wed, Apr 13, 2011 at 7:23 AM, Michael Dale md...@wikimedia.org wrote: Very cool. Especially given the development trajectory of Ace to become the eclipse of web IDEs there will be a lot of interesting possibilities as we could develop our own mediaWiki centric plugins for the platform. I can't help but think about where this is ideally headed ;) A gitorius type system for easy branching with mediaWiki.org code review style tools, with in browser editing. With seemless workflows for going from per user developing and testing on the live site, to commits to your personal repository, to being reviewed and tested by other developers, to being enabled by interested users, to being enabled by default if so desired. [snip lots of awesome sauce] I, for one, welcome our new integrated development overlords! :D I started up a page of notes and smaller steps on the road to awesomeness which we can start expanding on: http://www.mediawiki.org/wiki/Gadget_Studio The main things I want to hit in the immediate future are syntax highlighting (including clear detection of parse errors, which I don't think Ace does yet) for editing gadgets and site user scripts. For the upcoming parser stuff we'll want to do lots of experiments, and rapid prototyping the JavaScript-side implementations seems like a good way to get stuff into preliminary testing quickly, so being able to tweak code and immediately re-run it on something is going to be nice. I like the idea of being able to work on a core or extension JS module in-place too though, that could be interesting. :) Not everything will be amenable to being reloaded in the middle of a page view, but things that are could benefit from that kind of testing turnover. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85580]: Revision status changed
User Catrope changed the status of MediaWiki.r85580. Old Status: fixme New Status: resolved Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85580#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85655]: New comment added
User Kaldari posted a comment on MediaWiki.r85655. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85655#c15918 Comment: This code (along with r85606 and r85648) sets up basic lightboxing behavior for the image thumbnails. Instead of the thumbnails linking to the full-size image, they will now open a modal dialog box containing a large thumbnail image instead. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Syntax-highlighting JS CSS code editor gadget embedding Ace
Just came across jsfiddle ( http://jsfiddle.net/ ) via d3 ( https://github.com/mbostock/d3 ) http://jsfiddle.net/mbostock/EVnvj/ Uses CodeMirror http://codemirror.net/ -J -Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Brion Vibber Sent: 13 April 2011 18:31 To: Wikimedia developers Subject: Re: [Wikitech-l] Syntax-highlighting JS CSS code editor gadget embedding Ace On Wed, Apr 13, 2011 at 7:23 AM, Michael Dale md...@wikimedia.org wrote: Very cool. Especially given the development trajectory of Ace to become the eclipse of web IDEs there will be a lot of interesting possibilities as we could develop our own mediaWiki centric plugins for the platform. I can't help but think about where this is ideally headed ;) A gitorius type system for easy branching with mediaWiki.org code review style tools, with in browser editing. With seemless workflows for going from per user developing and testing on the live site, to commits to your personal repository, to being reviewed and tested by other developers, to being enabled by interested users, to being enabled by default if so desired. [snip lots of awesome sauce] I, for one, welcome our new integrated development overlords! :D I started up a page of notes and smaller steps on the road to awesomeness which we can start expanding on: http://www.mediawiki.org/wiki/Gadget_Studio The main things I want to hit in the immediate future are syntax highlighting (including clear detection of parse errors, which I don't think Ace does yet) for editing gadgets and site user scripts. For the upcoming parser stuff we'll want to do lots of experiments, and rapid prototyping the JavaScript-side implementations seems like a good way to get stuff into preliminary testing quickly, so being able to tweak code and immediately re-run it on something is going to be nice. I like the idea of being able to work on a core or extension JS module in-place too though, that could be interesting. :) Not everything will be amenable to being reloaded in the middle of a page view, but things that are could benefit from that kind of testing turnover. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85671]: Revision status changed
User ^demon changed the status of MediaWiki.r85671. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85671#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84535]: Revision status changed
User Catrope changed the status of MediaWiki.r84535. Old Status: resolved New Status: reverted Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/84535#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Change in Bugzilla's defaults
Until today, an advanced query in our Bugzilla's installation defaulted to returning bugs marked “WONTFIX” and “LATER”. Rob and I agreed that we didn't think this wasn't the behavior most people want so I changed it to remove those resolutions from the defaults. Another change I made was to adjust the default priority to “Low” from “Normal” so that most bugs don't end up in the priority level that I want to use for “This should be fixed by next release”. Perhaps many new bugs should be a priority, but I'd like there to be more than just one person complaining before the priority is raised. Finally, I changed the default severity to “Normal” from “Enhancement”. “Enhancement” is used for feature requests and most things coming into Bz are not feature requests, but are actual bugs. Just wanted you guys to have a heads-up in case you thought something was amiss. Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85962]: Revision status changed
User Catrope changed the status of MediaWiki.r85962. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85962#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85965]: Revision status changed
User Catrope changed the status of MediaWiki.r85965. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85965#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Change in Bugzilla's defaults
On Wed, Apr 13, 2011 at 2:01 PM, Mark A. Hershberger mhershber...@wikimedia.org wrote: Until today, an advanced query in our Bugzilla's installation defaulted to returning bugs marked “WONTFIX” and “LATER”. We changed this awhile back because we wanted to encourage people to search for dupes. With built-in dupe search now, I'm not sure this is quite so necessary anymore. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85207]: New comment added
User Bryan posted a comment on MediaWiki.r85207. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85207#c15919 Comment: Done in r85966. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85967]: Revision status changed
User Catrope changed the status of MediaWiki.r85967. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85967#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85968]: Revision status changed
User Catrope changed the status of MediaWiki.r85968. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85968#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85920]: Revision status changed
User ^demon changed the status of MediaWiki.r85920. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85920#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85973]: New comment added
User Kaldari posted a comment on MediaWiki.r85973. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85973#c15920 Comment: The -5 is for the file extension, e.g. .jpeg ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85891]: Revision status changed
User DieBuche changed the status of MediaWiki.r85891. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85891#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85887]: Revision status changed
User DieBuche changed the status of MediaWiki.r85887. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85887#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85880]: Revision status changed
User DieBuche changed the status of MediaWiki.r85880. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85880#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Change in Bugzilla's defaults
On 13.04.2011, 22:01 Mark wrote: Another change I made was to adjust the default priority to “Low” from “Normal” so that most bugs don't end up in the priority level that I want to use for “This should be fixed by next release”. Perhaps many new bugs should be a priority, but I'd like there to be more than just one person complaining before the priority is raised. This may piss people off (what? my bug is not in their plans?!). From a psychological perspective, it would be better to leave normal as default priority and consider high priority as This should be fixed by next release, IMHO. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Change in Bugzilla's defaults
Max Semenik wrote: On 13.04.2011, 22:01 Mark wrote: Another change I made was to adjust the default priority to “Low” from “Normal” so that most bugs don't end up in the priority level that I want to use for “This should be fixed by next release”. Perhaps many new bugs should be a priority, but I'd like there to be more than just one person complaining before the priority is raised. This may piss people off (what? my bug is not in their plans?!). From a psychological perspective, it would be better to leave normal as default priority and consider high priority as This should be fixed by next release, IMHO. -- Best regards, Max Semenik ([[User:MaxSem]]) I agree. Defaulting new bugs to a low priority doesn't seem very friendly to new users. They don't know (and shouldn't have to know) what the bugmeister's organization is. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85988]: New comment added
User MaxSem posted a comment on MediaWiki.r85988. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85988#c15921 Comment: Please explain what that bug is about in commit summary, it's much easier to review this way. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85988]: New comment added
User DieBuche posted a comment on MediaWiki.r85988. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85988#c15922 Comment: Ok, will do next time ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Change in Bugzilla's defaults
On Wed, Apr 13, 2011 at 2:44 PM, Krinkle krinklem...@gmail.com wrote: I agree. Defaulting new bugs to a low priority doesn't seem very friendly to new users. They don't know (and shouldn't have to know) what the bugmeister's organization is. Then make a triage priority and default them all to that. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Registration open for the Hackathon in Berlin, May 13-15
On 04/09/2011 02:11 PM, Neil Kandalgaonkar wrote: I assume those of us who thought they registered via the WMF (but apparently didn't) don't need to do anything? Yeah, don't worry about it, Carrie at WMF Cornelius from WMDE are taking care of it. -Sumana ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bug priorities (Re: Change in Bugzilla's defaults)
On Wed, Apr 13, 2011 at 12:44 PM, Krinkle krinklem...@gmail.com wrote: I agree. Defaulting new bugs to a low priority doesn't seem very friendly to new users. They don't know (and shouldn't have to know) what the bugmeister's organization is. I thought about replying with a similar response, but then I realized that if Mark stays on top of incoming bugs (which is his job), he'll be able to bump bugs up to normal as they come in, which should actually make those people good, and provide some automatic positive reinforcement for filing important bugs. I suspect most people won't even notice that the bug defaults to low, and they'll be able to fix it if they disagree. I suppose the best thing would be to have a blank priority (or triage as OQ suggests), so that we could query for the bugs that haven't been explicitly prioritized, but I don't know if that's possible. This isn't so narrowly focused on the bugmeister as it is starting to pay attention to the priority field as a community. All priorities should have a meaning for us. We can debate about what is correct, but here's what my thinking is: 1. Highest - this means a bug that someone is either working on *right now*, or at least should be working on right now. No developer should have more than one highest priority bug, and anything marked highest priority shouldn't stay unassigned for more than a week. 2. High - this means that a bug is in the relatively-small pool of bugs that will likely get bumped to highest priority. Bugs at this priority should, at a minimum, be blockers for the next release of the software. 3. Normal - these are bugs that really should get fixed for the next release of the software. They aren't necessarily blockers, and we may grit our teeth and have a release or two with this bug, but there's no way we should go two releases with a normal priority bug. 4. Low - these are bugs that we won't actively manage. They may be important to some people, and someone may get around to fixing the problem, but no developer is committed to working on a fix 5. Lowest - these are bugs that pretty much everyone agrees aren't terribly important (including the reporter). I'm not wedded to these exact definitions, but I'm pretty wedded to the idea that we should agree on something. I don't think we should consider it normal to have bugs go for years without activity. From a practical perspective, many more bugs than are being marked as normal are actually normal by this standard. Most of the bugs in our database are probably low priority in the sense that we just can't get around to fixing all of them. I can see the argument for making the most common case the default (though I share others uneasiness with doing so). Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Registration open for the Hackathon in Berlin, May 13-15
Thanks for correcting my error, Danese! Sorry. I should instead say: if Carrie says to do something, then yes, you need to do it. :-) -Sumana On 04/13/2011 04:18 PM, Danese Cooper wrote: Not quite right, Sumana...the folks Carrie wrote to over the weekend need to make sure they are registered. I thought I'd done it, but the registration site couldn't find me:-(. It takes no time, but you're not *really* registered until you get the email receipt from the registration server. D On Wed, Apr 13, 2011 at 1:12 PM, Sumana Harihareswarasuma...@panix.comwrote: On 04/09/2011 02:11 PM, Neil Kandalgaonkar wrote: I assume those of us who thought they registered via the WMF (but apparently didn't) don't need to do anything? Yeah, don't worry about it, Carrie at WMF Cornelius from WMDE are taking care of it. -Sumana ___ 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] Bug priorities (Re: Change in Bugzilla's defaults)
On Wed, Apr 13, 2011 at 1:15 PM, Rob Lanphier ro...@robla.net wrote: From a practical perspective, many more bugs than are being marked as normal are actually normal by this standard. Most of the bugs in our database are probably low priority in the sense that we just can't get around to fixing all of them. I can see the argument for making the most common case the default (though I share others uneasiness with doing so). It may be worth having an unassigned initial priority, which we can treat as equivalent to low. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85914]: Revision status changed
User Catrope changed the status of MediaWiki.r85914. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85914#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85922]: New comment added
User Svippong posted a comment on MediaWiki.r85922. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85922#c15923 Comment: After these changes, tables are behaving incorrectly. For instance, if you have a header in a table cell, it won't render correctly if it is at the beginning of the cell. e.g. pre| === Foo ===/pre Will not render correctly, but pre| === Foo ===/pre will. In addition, tables which appear further down on pages seems to have a margin-top: 50% behaviour. This is probably overwriteable with CSS, but it seems to be an odd default behaviour. Some examples: * http://theinfosphere.org/Broadcast_season_8#Season_8 * http://theinfosphere.org/Main_Page (notice the lack of header rendering for some of the headers in the table) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85483]: Revision status changed
User Catrope changed the status of MediaWiki.r85483. Old Status: fixme New Status: resolved Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85483#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85969]: Revision status changed
User Catrope changed the status of MediaWiki.r85969. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85969#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Call for UI bugs
2011/4/13 Mark A. Hershberger mhershber...@wikimedia.org: This coming week, I'd like to focus on any User Interface bugs. Here are a couple of bugs that show up to people who like their paragraphs justified and set up their preferences accordingly: https://bugzilla.wikimedia.org/show_bug.cgi?id=20184 https://bugzilla.wikimedia.org/show_bug.cgi?id=28359 I may be naïve, but both should be fairly easy to fix. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com We're living in pieces, I want to live in peace. - T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85974]: Revision status changed
User Trevor Parscal changed the status of MediaWiki.r85974. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85974#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85964]: Revision status changed
User Trevor Parscal changed the status of MediaWiki.r85964. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85964#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85575]: Revision status changed
User Catrope changed the status of MediaWiki.r85575. Old Status: fixme New Status: resolved Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85575#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85922]: New comment added
User Platonides posted a comment on MediaWiki.r85922. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85922#c15924 Comment: - if ( $line === '' ) { # empty line, go to next line + if ( $line == '') { //empty line, go to next line Why are you changing the strict equality to a weak one? Probably introduces some bug. :Oh, it was fixed in r85943 You're changing the tag history to using a stack. I'd appreciate some docs on the way it is done. It's probably ok, but would be easier to review it with an explanations. Also, the new way looks more memory hungry. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85922]: New comment added
User Platonides posted a comment on MediaWiki.r85922. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85922#c15925 Comment: I think that's due to the trim(). As the goal of this revision was to add thead/tfoot, I think it could be stripped back. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85943]: New comment added
User Platonides posted a comment on MediaWiki.r85943. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85943#c15926 Comment: You should add a parser test. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Change in Bugzilla's defaults
Max Semenik maxsem.w...@gmail.com writes: This may piss people off (what? my bug is not in their plans?!). How is that different from how we've been pissing people off with ~2500 bugs against MediaWiki that were opened more than six months ago and have sat, ignored, without resolution. I think we're already pretty effectively communicating to a lot of people that their bug is not in our plans. I'm trying to find ways to deal with that. In the mean time, no one is stopping someone from changing the priority if they feel it is justified. Krinkle krinklem...@gmail.com writes: Defaulting new bugs to a low priority doesn't seem very friendly to new users. They don't know (and shouldn't have to know) what the bugmeister's organization is. You're right: they don't need to know anything about how I'm trying to manage things. Still, the priority field isn't being used only by me. Rob and I have been discussing how to we can use it to manage the real priority for each developer and component in Bugzilla. We're getting closer to that and you should see the assignments of bugs changing as we make the use of the more intuitive meaning of “priority”. Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85922]: New comment added
User Platonides posted a comment on MediaWiki.r85922. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85922#c15927 Comment: Did you run the parserTests after your changes? You also broke other 3 parserTests: * Fuzz testing: Parser14-table... * Fuzz testing: Parser22... * Bug 529: Uncovered table already at line-start... I don't think it's important that there's no longer a table in those Fuzz testing tests, but in such case I'd expect the {| to appear as a literal, not to magically disappear. The change to 'Uncovered table already at line-start' is wrong. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Call for UI bugs
Just to be sure with this, we're not talking about justifying paragraphs by default? Users must set this preference? The reason I ask is that paragraph justification is a rather massive no-no when it comes to usability regarding readers with dyslexia and some types of visual impairment. On 4/13/11 1:58 PM, Amir E. Aharoni wrote: 2011/4/13 Mark A. Hershbergermhershber...@wikimedia.org: This coming week, I'd like to focus on any User Interface bugs. Here are a couple of bugs that show up to people who like their paragraphs justified and set up their preferences accordingly: https://bugzilla.wikimedia.org/show_bug.cgi?id=20184 https://bugzilla.wikimedia.org/show_bug.cgi?id=28359 I may be naïve, but both should be fairly easy to fix. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com We're living in pieces, I want to live in peace. - T. Moore ___ 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] Bug priorities (Re: Change in Bugzilla's defaults)
Brion Vibber br...@pobox.com writes: On Wed, Apr 13, 2011 at 1:15 PM, Rob Lanphier ro...@robla.net wrote: From a practical perspective, many more bugs than are being marked as normal are actually normal by this standard. Most of the bugs in our database are probably low priority in the sense that we just can't get around to fixing all of them. I can see the argument for making the most common case the default (though I share others uneasiness with doing so). It may be worth having an unassigned initial priority, which we can treat as equivalent to low. We can do this, I think, by changing the bug's state from “NEW” to “ASSIGNED”. Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Call for UI bugs
2011/4/14 Brandon Harris bhar...@wikimedia.org: Just to be sure with this, we're not talking about justifying paragraphs by default? Users must set this preference? Yes. I usually turn it on; now you made me consider turning it off. The reason I ask is that paragraph justification is a rather massive no-no when it comes to usability regarding readers with dyslexia and some types of visual impairment. It's somewhat off topic, but very interesting. Thanks a lot for sharing it. Please consider improving the paragraph about this issue in the article [[Justification (typesetting)]] :) -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com We're living in pieces, I want to live in peace. - T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Centralize PHP (and other) minimum requirements / MoveDefines.php up the call stack
Happy-melon wrote: What I have done is to move the PHP version check from WebStart.php (which was unparseable since Tim added a try/catch block in r85327) to the entry points index.php, api.php, load.php. That way, only those files have to be PHP 4 compatible. Don't forget about update.php and install.php ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85973]: New comment added
User Bryan posted a comment on MediaWiki.r85973. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85973#c15928 Comment: Note that the maximum length is 255 bytes, while maxlength sets the maximum amount of characters, as far as I know. So you should still take care that you catch maximum length violations. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85982]: Revision status changed
User Krinkle changed the status of MediaWiki.r85982. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85982#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Bug priorities (Re: Change in Bugzilla's defaults)
From a practical perspective, many more bugs than are being marked as normal are actually normal by this standard. Most of the bugs in our database are probably low priority in the sense that we just can't get around to fixing all of them. I can see the argument for making the most common case the default (though I share others uneasiness with doing so). A good thing is that if the default is normal and the bugmeister then lowers it, that gives a negative feedback to the reporter, whereas if it's as the default, it doesn't. Most bugs that are bugs should be normal, but perhaps we don't have the resources to fix each of them. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85990]: Revision status changed
User Catrope changed the status of MediaWiki.r85990. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85990#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85902]: New comment added
User Helder.wiki posted a comment on MediaWiki.r85902. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85902#c15929 Comment: Great! :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Call for UI bugs
Amir E. Aharoni amir.ahar...@mail.huji.ac.il writes: Here are a couple of bugs that show up to people who like their paragraphs justified and set up their preferences accordingly: https://bugzilla.wikimedia.org/show_bug.cgi?id=20184 https://bugzilla.wikimedia.org/show_bug.cgi?id=28359 I've added the “triage” keyword to #28359 and added a comment pointing back to #20184. I didn't add “triage” to earlier bug because I *am* trying to restrict triage to fairly current bugs. Feel free to add the “triage” keyword to any other bugs you find that fit the “recent UI bug” criteria. Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r82120]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r82120. Old Status: new New Status: fixme User Brion VIBBER also posted a comment on MediaWiki.r82120. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82120#c15930 Comment: This causes a fatal error because it tries to pass a Title object (the second parameter of ContibutionsToolLinks, which is the title of the user page) to a function expecting a User object. It then dies because the Title object doesn't have a getName() parameter. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85973]: New comment added
User Kaldari posted a comment on MediaWiki.r85973. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85973#c15931 Comment: True. This is just a quick fix for latin scripts. Will work on a more comprehensive checking mechanism soon. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r82120]: Revision status changed
User Happy-melon changed the status of MediaWiki.r82120. Old Status: fixme New Status: reverted Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82120#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85998]: New comment added
User Trevor Parscal posted a comment on MediaWiki.r85998. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85998#c15932 Comment: Line 106 + $data2[$userData['revid']]['ratings'][$id]['count']++; Should be + if ( $value ) { + $data2[$userData['revid']]['ratings'][$id]['count']++; + } ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86000]: Revision status changed
User Trevor Parscal changed the status of MediaWiki.r86000. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86000#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85998]: Revision status changed
User Trevor Parscal changed the status of MediaWiki.r85998. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85998#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85998]: New comment added, and revision status changed
User Catrope changed the status of MediaWiki.r85998. Old Status: resolved New Status: new User Catrope also posted a comment on MediaWiki.r85998. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85998#c15933 Comment: I did this in r86000, 5 seconds after you wrote this ;) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86001]: New comment added, and revision status changed
User Siebrand changed the status of MediaWiki.r86001. Old Status: new New Status: fixme User Siebrand also posted a comment on MediaWiki.r86001. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86001#c15934 Comment: Please fix the out-of-context reuse of the message key 'history' in 'historywarning'. That needs its own key (suggestion: 'historywarning-history'). But why not just use [$2 history]? This would make L10n a lot easier and clear. Patchwork messages are bad. See [[Localization#Avoid_patchwork_messages]]. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86001]: Revision status changed
User Happy-melon changed the status of MediaWiki.r86001. Old Status: fixme New Status: reverted Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86001#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86011]: New comment added
User Jack Phoenix posted a comment on MediaWiki.r86011. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86011#c15935 Comment: Some minor [[Manual:Coding conventions|coding style]] issues here: *$welcome_creation_msg should be called $welcomeCreationMsg *I'd prefer a space after the double slashes: code// let any extensions change what message is shown/code *space after ) and before { (codeif( $msgname ) {/code) docs/hooks.txt should also be updated. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86015]: New comment added, and revision status changed
User Reedy changed the status of MediaWiki.r86015. Old Status: new New Status: fixme User Reedy also posted a comment on MediaWiki.r86015. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86015#c15936 Comment: You shouldn't ever be using $_GET or $_POST directly It also has mixed indenting, mixed code style (which isn't the MW style) More often than not, using echo is the wrong thing to do ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86011]: New comment added
User Reedy posted a comment on MediaWiki.r86011. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86011#c15937 Comment: Also, an onwiki Manual page should be created for the hook ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86014]: Revision status changed
User Reedy changed the status of MediaWiki.r86014. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86014#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85996]: Revision status changed
User Reedy changed the status of MediaWiki.r85996. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85996#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85993]: Revision status changed
User Reedy changed the status of MediaWiki.r85993. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85993#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85993]: New comment added
User Jeroen De Dauw posted a comment on MediaWiki.r85993. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85993#c15939 Comment: That also seems to work, which I find rather odd, since there must be some reason I started using the while loop instead of a simple foreach at some point. Any idea why that would be? Maybe this did not work with MW 1.15.x or so? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85993]: New comment added
User Reedy posted a comment on MediaWiki.r85993. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85993#c15940 Comment: Nope. It's been the case as long as I can remember.. God knows! Heh :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86017]: Revision status changed
User Reedy changed the status of MediaWiki.r86017. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86017#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86016]: Revision status changed
User Reedy changed the status of MediaWiki.r86016. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86016#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85993]: New comment added
User Reedy posted a comment on MediaWiki.r85993. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85993#c15938 Comment: pre while ( $vote = $votes-fetchObject() ) { /pre should really be pre foreach( $votes as $vote ) { /pre ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85989]: Revision status changed
User Krinkle changed the status of MediaWiki.r85989. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85989#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85995]: Revision status changed
User Reedy changed the status of MediaWiki.r85995. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85995#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview