Bug management/Triage/Archive/1

Bug Triage @ Weekly Wikimedia Tech Meeting

Agenda

 * Triage @ Mon, May 23; West Coast; 23:00 GMT
 * Triage @ Mon, May 30; Europeans+US; 19:00 GMT / Noon PDT

Open Bugs for Mon, May 23

 * https://bugzilla.wikimedia.org/28840 Loader broken in IE because mediawiki thinks the periods in module names is a security leak (spoof extension)
 * Is the work-around in place permanent?
 * https://bugzilla.wikimedia.org/28962 ajax calls with '.' not working in IE
 * Status of review of Roan's code?
 * in BZ is marked as dependent on the above; is it all the same fix?
 * check with Tim+Roan for an update on status!


 * https://bugzilla.wikimedia.org/28857 Sometimes there's "undefined" in a Resource loader CSS request
 * Trevor is assigned: Status?
 * Check with Trevor for status


 * http://bugzilla.wikimedia.org/28829 Failure to subscribe to mediawiki-announce is not reported to the user
 * Need to assign this to someone
 * need to have fixed in the tarball, declares Mark
 * Chad says "I can do that, it's installer."


 * http://bugzilla.wikimedia.org/21653 Normal NEW Creating a PDF with collection extension does not render the tag hook from proofread page extension
 * in PDF: sounds like it'll need support on the generator; ping the PediaPress guys for what would be needed. (Need to confirm how these are used.)
 * http://bugzilla.wikimedia.org/26448 Normal NEW Make Collection extension to automatically create collections for existing books on Wikibooks/Wikisources
 * Who takes care of PediaPress bugs? Do we talk to anyone there?
 * Good question! brion was.
 * Offline. Tomasz.
 * rendererererer.... best if they could do it
 * for the first one, generator-side fix. 2nd, might be doable in wiki side, have to look up setup
 * alternate collection format: sounds like it'll all be on the MediaWiki extension side; completed collections will be sent off to the PDF generator in bulk.


 * http://bugzilla.wikimedia.org/27858 Normal NEW Block notice when editing talk page of blocked user doesn't go away after block expires
 * Is this really a MW bug?
 * should be a big notice: you are editing the talk page of a blocked user. Reference: https://secure.wikimedia.org/wikipedia/en/w/index.php?title=User_talk:76.22.193.206&action=edit&redlink=1
 * should not be cached, and I should see it every time I visit the page during the block.
 * Brion to put note on bug here, investigate offline
 * *Sounds like* a straightforward caching issue, may be an easy fix depending on how much work we can do at block expiration time.


 * http://bugzilla.wikimedia.org/28026 Normal REOPENED Enable e-mail notifications for watchlist (EnotifWatchlist) on all small wikis
 * Reedy tried to do it today. Want to try again?
 * I thought it was another bug
 * bring up with Tim
 * lower the priority. Mark.


 * http://bugzilla.wikimedia.org/28961 Normal NEW $wgUseDumbLinkUpdate and $wgPagePropLinkInvalidations maybe not working
 * Comment says Tim introduced this 3 years ago (http://www.mediawiki.org/wiki/Special:Code/MediaWiki/31113 )
 * Is this a regression?
 * I doubt it, most of this hasn't changed in several releases, at the very least.
 * Mark to update bug


 * https://bugzilla.wikimedia.org/6100 Allow different directionality (rtl/ltr) for user interface and wiki content
 * Berlin attendees really really want this fixed!
 * This is the RTL bug according to the RTL triage last week.
 * See also next bug.
 * RobLa: in 1.17, there was movement in this direction. What ended up happening: discovered many problems as we did this.  IIRC, Tim reverted after seeing many problems introduced. http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81622
 * Brion: is there a summary of those issues?
 * Neeed Tim! TimStarling, you are our only primary hope!
 * Mark to ping Tim
 * Probably a "big project" that'll need lots of effort on cleaning up little things, and testing issues in deployment.


 * http://bugzilla.wikimedia.org/28970 Normal NEW there's no clean way to indicate the directionality of the content of the page (RTL)
 * New bug from Berlin "there will have to be a way to indicate the directionality of the page."
 * Anybody want to help Amir bring this to implementation? or just do it.
 * suggested: checkbox for "this is an LTR page on an RTL wiki"
 * if going to do this, should probably be a language selector: RTL is just one of several properties controlled by language/script selection. This is an enhancement issue, and probably warrants an experimental extension that can be deployed to Meta, Commons and other multi-lingual sites to verify that it makes sense before going core with it.
 * Mark to ping Tim


 * http://bugzilla.wikimedia.org/29032 Normal NEW Case confusion in login error messages
 * Clarify message to avoid confusion?
 * discussed with Chad. Bug reporter's request is unclear.  Reporter thought he sensed a global auth problem -- en.wiki or cross-domain check? Reporter is wrong on second point.
 * message fix - Mark to write new language & fix


 * http://bugzilla.wikimedia.org/26544 Normal NEW Missing CSS for .redirectText
 * Krinkle asked for Triage
 * Krinkle wants to discuss with Trevor. Design choice?  Forgotten?  Trivial to fix
 * Krinkle is disturbed by live transcription
 * Are links too small? smaller? screenshot requested: http://www.mediawiki.org/w/index.php?title=Sandbox2&redirect=no  Want consistent size in Vector... inconsistent font sizes inappropriately used for emphasis in Monobook.
 * What text would be affected here, labelled with Redirect class? affected text: pagename inside a redirect=no page, clickable, redirect text
 * Looks fine as it is. INVALID or WONTFIX suggested by Brion
 * Brion closing as INVALID but including examples
 * Reopened -- as noted, the previous test link was useless because the Vector styles on en.wikipedia.org (but the link was to mediawiki.org what link? my links were to en.wikipedia.org and there were no previous links such as an explanation in the original comment or an example URL linked on the bug up there ^ oh i never saw that link, it doesn't appear to be on the bug) had been customized to hide the issue. It still looks fairly decent as is, though. lol
 * Reopened -- as noted, the previous test link was useless because the Vector styles on en.wikipedia.org (but the link was to mediawiki.org what link? my links were to en.wikipedia.org and there were no previous links such as an explanation in the original comment or an example URL linked on the bug up there ^ oh i never saw that link, it doesn't appear to be on the bug) had been customized to hide the issue. It still looks fairly decent as is, though. lol


 * http://bugzilla.wikimedia.org/27678 Normal NEW No result given when searching using "offset" option in Special:IndexPages
 * Last comment includes a possible new bug.
 * part of ProofreadPage extension which desperately needs a complete rewrite. If fix isn't obvious, leave it for later.
 * Thomas V - fix will need a second pair of eyes. Default assignee for these bugs.
 * Mark to contact Thomas.


 * http://bugzilla.wikimedia.org/28986 Normal NEW the code to normalize widths of images in Linker is scary and really belongs somewhere else.
 * New linker project, like new parser? NO. Belongs in MediaHandler classes or common code used by everything - no functional issue, just refactoring & cleanup.  Low priority.
 * bawolff opened, assigned to derk-jan
 * no action needed


 * http://bugzilla.wikimedia.org/26881 Normal REOPENED noinclude tag breaks Proofread under Internet Explorer
 * Proofread, who does it? (Also reCaptcha?)
 * ThomasV, per above.


 * https://bugzilla.wikimedia.org/26676 - tracking issue for 1.17 release tarball
 * https://bugzilla.wikimedia.org/28172 - Error on Postgres install - wfGetDB called when it shouldn't
 * Chad has no desire to play with Postgres anymore, post-installer-trauma
 * needs a fix for 1.17
 * Mark to try to do this


 * https://bugzilla.wikimedia.org/28845 - PostgresInstaller::canCreateAccounts gives the wrong result
 * Chad is requested, declines.
 * Priyanka? Will you take the ring, though you do not know the way?  Declined
 * Mark to do this one too, Tuesday
 * RobLa: Tim is the lead on this, will have to figure out how to dole assignments out. If Mark cannot get to these and they become an issue blocking 1.17 release -- along with dots & !s in URLs -- we need to push to either triage this out of 1.17 release, or fix it, staff or volunteers, by release.  Also, mark email issue as blocker (bug #?)  Mark to mark that.
 * Other 1.17 blockers: bugs 28962 and 28829 discussed above

Meeting next week: scheduled for noon Monday Pacific Time, which is in the middle of a holiday. Resched?? midday Wed June 1st

What's the next thing we want to triage? ondisk / database parser cache 1.18 deploy -- trying to do before Wikimania.... do not deploy & run! About 800 new revs, and 2 dozen fixmes for 1.18: CodeReviewTracker

Open bugs for Mon, May 9
Requests


 * http://bugzilla.wikimedia.org/11415: High NEW __EDITPARENTSECTION__
 * Old enhancement, but looks like it is frequently needed
 * low prioity, could be messy
 * bugsmash


 * http://bugzilla.wikimedia.org/20814: Low NEW Enable $wgCrossSiteAJAXdomains for wikimedia sites
 * Seeking comment from Tim: Is this a reasonable shell request? Security implications?
 * safe, but awkward, questions shell needs answered: specific tools, is it safe, list of domains


 * http://bugzilla.wikimedia.org/28819: Normal NEW Deleted revision links should use "rev_id" not "page/timestamp"
 * http://bugzilla.wikimedia.org/28820: Normal NEW Diffs using rev_id should work when one or both revisions are deleted
 * http://bugzilla.wikimedia.org/18104: Low NEW Schema request change so deleted edits are identified by revisionID not timestamp (prevents DIFFs from breaking)
 * bugsmash


 * http://bugzilla.wikimedia.org/28843: Normal NEW Customizable cite error
 * Spawned from http://bugzilla.wikimedia.org/16854
 * Also http://bugzilla.wikimedia.org/22323 Tag cite error revisions
 * How important?
 * How

Regressions, errors


 * http://bugzilla.wikimedia.org/28851: Highest NEW Display problem on ku.wikipedia
 * This is likely be caused one of the other general CSS-breakage or RL-breakage issues -- revisit when others are fixed to confirm it's not still happening. (Could be the server bug from before, if stuff didn't get cleared.)


 * http://bugzilla.wikimedia.org/28857: High NEW Sometimes there's "undefined" in a Resource loader CSS request
 * See also http://bugzilla.wikimedia.org/28714 from last week
 * check on roan's patch
 * ie5.5 workaround related?


 * http://bugzilla.wikimedia.org/28889: High NEW out of memory error when deleting messages on commons
 * related to customization of messages in mediawiki namespace which is highly customized on commons
 * if just that page, then not high priority


 * http://bugzilla.wikimedia.org/28827: High NEW PHP Catchable fatal error:  Argument 1 passed to RequestContext::setTitle must be an instance of Title, null given
 * someone want to dig this up?
 * get someone who is responsible for this to look


 * http://bugzilla.wikimedia.org/28891: Normal NEW Regression? Clicking on non-existing image link does not redirect to upload anymore
 * looks like probably the same cause as 28840 -- hits IE users. Filename on the URL oughta be legit... and since we're sending HTML anyway that should always override shouldn't it? (or... does it)


 * http://bugzilla.wikimedia.org/28840: High NEW Diffs not displaying correctly in IE because mediawiki thinks the periods in module names during load requests is someone trying to spoof extension and do the evil IE6 thing
 * 1.16.5 issue?
 * We think caching issues may be causing this to break for non-IE users in production?
 * A workaround is in trunk & 1.17wmf1 for RL, but this won't fix 28891.


 * http://bugzilla.wikimedia.org/28842: High NEW user rights issue with vector and new editor
 * 1.16.5 issue?
 * tim is on it, thinks it is an extension


 * http://bugzilla.wikimedia.org/28829: Highest NEW Failure to subscribe to mediawiki-announce is not reported to the user
 * bugsmash


 * http://bugzilla.wikimedia.org/28845: Normal NEW PostgresInstaller::canCreateAccounts gives the wrong result
 * Can we reproduce this or is it only something heard once on IRC?
 * 1.17 postgres fix, bugsmash


 * http://bugzilla.wikimedia.org/28839: Normal NEW Interwiki may circumvent blacklist
 * Is chad's response ("Don't do that") the right one?
 * that's pretty much been our traditional response yes; like URL shorteners they can trivially link to almost anything, and it's probably easy to wriggle around any blacklist entry that might work.
 * Removing the 'cache' iw prefix would not be unreasonable also. SEEK AND DESTROY existing links. ;)
 * however, it should be straightforward to run inline interwiki links through the URL blacklists for triggering on regexes, and it might make people happier. External links are fetched through parser so should be able to just pull the iwlinks too.
 * [bugsmash?]

Open bugs for Mon, May 2

 * http://bugzilla.wikimedia.org/28499: High NEW Error 1205: Lock wait timeout exceeded; try restarting transaction (tracking)
 * Update from Sam?
 * [stats given]:
 * Totals (for all of April):
 * Deadlock total count: 8703
 * Lock wait timeout total count:145821
 * Dupe entry total count: 994
 * Total number of errors: 147809
 * Broken down by method:
 * User::invalidateCache 137454 - we know this is bad
 * https://bugzilla.wikimedia.org/show_bug.cgi?id=20468
 * https://bugzilla.wikimedia.org/show_bug.cgi?id=23339
 * Higher priority. Chad: easiest fix is, as domas points out, stop calling it so many places.  Some places, we don't need to.  Limit some errors.  Notwithstanding what problems are IN the method itself.
 * http://svn.wikimedia.org/doc/classUser_a124949b4a526ad6885f7f98816d3862d_icgraph.png
 * Block::purgeExpired 5734
 * Article::updateCategoryCounts 4972
 * SiteStatsUpdate::doUpdate 3595
 * GlobalUsage::insertLinks 689
 * Title::invalidateCache 624
 * FlaggedRevision::insertOn 568
 * Job::pop 484
 * User::addToDatabase 356
 * Block::delete 127
 * Block::insert 108
 * LinksUpdate::incrTableUpdate 106
 * LinksUpdate::invalidatePages 100
 * Move 28499 to low priority
 * normal-to--low priority. tiny proportion of errors?  How bad is this?  Sam to take another look at this.
 * Moved from April 18, 2011 / BugTriage notes:
 * http://bugzilla.wikimedia.org/28499: High NEW 1205: Lock wait timeout exceeded; try restarting transaction (tracking)
 * yes, this is as above. complicated database issues.  Need Tim.
 * RobLa asks Sam to investigate, file a ticket with ops or as appropriate. OK to postpone for a few days. Need something over a slightly longer stretch of time than 5 minutes!
 * comparison: if we see high CPU usage, we see it consistently high on the graphs, and then after fix is deployed, we see it decrease! can't fix without baselines, measurements!  This kind of measurement is a prereq to seriously trying to fix this or related bugs
 * /home/wikipedia/l/archive - we has teh logs


 * http://bugzilla.wikimedia.org/28714: Normal NEW pages showing up with no styling applied
 * cache or squid error. Possibly important?
 * happened to ROAN 1ce or twice in code review
 * intermittent, anecdotal.
 * One or two apaches returning bad data? or varnish is responding with bad data?
 * assign to Roan
 * curious why this is happening since it should almost never happen since caching is one month
 * Roan to investigate this


 * http://bugzilla.wikimedia.org/28626: High NEW JS syntax errors affect other modules in ResourceLoader
 * Someone pointed to GPL linter!
 * Has Brion looked at that? no. Brion to look


 * http://bugzilla.wikimedia.org/28762: Normal NEW Resizing to specified height broken for very thin images
 * Update from previous weeks
 * Bryan has found weird states where it is happening wrong.
 * What is the next step here???
 * ok so the patch for the actual sizing & 0-width issue has been broken out to this bug, separating it from the unrelated maximum-height issue on a particular special page
 * patch needs to be checked to see if it changes any 'real' image sizes and to confirm that it correctly ensures minimum single pixels without becoming inconsistent (since we refer to thumbs by their width, we can't have a 1px-wide image that's 50px high and another that's 500px high.)


 * http://bugzilla.wikimedia.org/19262: Normal NEW Pages with a high number of citation templates suffer extremely slow rendering or read timeout for logged in users
 * Seems like this should be a very high priority bug given the possible loss of data and recent complaints
 * domas brought this up a few weeks ago. Does warrant investigation.
 * Assign to RobLa, normal priority
 * RobLa to get update on where this fits in our plans.


 * http://bugzilla.wikimedia.org/28705: High NEW URL Normalization for diff link on history, watchlist, contributions, recent changes and diff page
 * http://bugzilla.wikimedia.org/28756: enhancement NEW Navigation of Special:Whatlinkshere is broken
 * Two for the price of one!
 * not a high priority at all -- all links do work, even if they go by diff names.


 * http://bugzilla.wikimedia.org/28720: Normal NEW Do not suppress conflicts for same user edits
 * Often happends when double-clicking submit or pressing Enter/Return twice from the edit summary –Krinkle
 * above? req to change behavior
 * current behavior is a workaround for bad behavior in a common case
 * that behavior still has some corner cases where it's not ideal
 * probably just an enhancement tag for 1/100 project?


 * http://bugzilla.wikimedia.org/28690: Normal NEW Vector dialog styling causes problems
 * jQuery UI related
 * Timo says: some [inaudible] were not ported from default skin
 * we need to tweak Vector skin for dialog
 * talk to kaldari
 * pretty trivial probably an easy fix.
 * default skin has a border around dialog. Timo will look tonight: easy fix


 * http://bugzilla.wikimedia.org/28739: Normal NEW in Special:MovePage the "Move page" button should be disabled until a new name was entered
 * easy JavaScript timo ? Assigned: Timo


 * http://bugzilla.wikimedia.org/28747: High NEW AntiSpoof should also check global accounts from CentralAuth
 * brion says needs an overall
 * umlaut example if we don't fix this, we will get complaints from admins who want to block people. But not a new issue.  Open for at least 3-4 years.
 * Normal priority. We don't really have an owner for Central Auth, so, general engineering?  Default assignee is not very active.  We should remove Victor as default assignee?  move to AntiSpoof component


 * http://bugzilla.wikimedia.org/28767: High NEW Internal error on Special:CentralAuth/username
 * probably a bad db entry, like a wiki that's been deleted or got stored with wrong code

Open bugs for Mon, April 25

 * http://bugzilla.wikimedia.org/28419: High NEW Replace MD5 password hashing with WHIRLPOOL
 * How important is this? 1.18?
 * "not convinced this is super-high priority". Look at it within the next year.
 * We are salting along with MD5. That's an additional layer of defense.
 * Tim thinks it is fairly high priority. Mark: Let's catch him and ask him about this offline or in the next Tim-present bug triage meeting.  Possibly a normal priority.  If not this release cycle, the next.


 * http://bugzilla.wikimedia.org/28673: High NEW Merge iwtransclusion branch into phase3
 * GSOC project from last year, which is why it is in a branch. We recommend doing those as extension or option.  Sumana notes this.
 * just continue pestering Roan to do this?
 * Sam has got this upto ~ r82000, so ~ 4k to SVN Head. Will finish this to the a near round number.. Peter seems to have some interest in doing this, but poking Roan to finish it off might be needed
 * good news! This had been discussed on foundation-l
 * high-priority enhancement!
 * had been sitting there for a long time, not merged.
 * has it been reviewed for architectural soundness & readiness to deploy?


 * http://bugzilla.wikimedia.org/28023: Normal NEW trims leading space
 * Do we care? should this be lower or higher?
 * All parser functions will strip a leading space like that; not worth special-casing default sort for something like this?
 * description is unclear -- does default sort strip the space? category doesn't?  Desire for consistency?  reasonable behavior for default sort, but unreasonable for other case?  category links... [not catching detail here]  If we decide to make a change for consistency, let's do some research, figure out what people are already doing, want.
 * Fairly esoteric case here. Pretty low priority, says RobLa.
 * "lowest priority, isn't urgent at all".


 * http://bugzilla.wikimedia.org/25404: High NEW Lucene search for simple text misses some results
 * http://bugzilla.wikimedia.org/28088: Normal NEW Search result snippets should skip parenthetical phrases
 * http://wikitech.wikimedia.org/view/Search
 * ok, but who can handle search besides rainman who isn't much available? Do we have any Java devs?
 * Are all the search indexes now up to date (ie the backlog cleared)?
 * Priyanka says: maybe we should just get some experience & domain skills on staff instead of always having to search for someone
 * Lucene is not that hard to play with; how well is our setup documented? Mark can understand it, not horrible.
 * Priyanka: HOW we use it, not doc'd very well. No idea how to repro it.  WHOOO?  RobLa, point at someone!
 * Rainman has access, as a volunteer. We do give that access to volunteers.  It's conceivable to give that access to others.  Rainman is out of time.
 * Someone in Ops may already have this in their head. [did not catch what Mark said at end]
 * I know Ariel/Peter have been working on it with Rainman (but may not know much)


 * http://bugzilla.wikimedia.org/28188: Normal NEW Can't upload PDF / ODF Hybrid
 * what is needed to enable this? how much risk is there?
 * Our security checks are working as intended by detecting that the files have been smashed together unexpectedly. Might be possible to tweak it to consider 'oh that's ok' but not sure how much we want to. If not careful might accidentally allow all sorts of evil appended to a PDF file.
 * Workaround: 'don't save your PDF that way'. (Problem with workaround: if someone else made the file, you might not know how to re-save it.)
 * ODF file is a ZIP file..... unholy abomination?
 * should we? 1.18?
 * This is an enhancement. Not a case we intended to support.
 * We do not allow upload of ODF files? Would basically be treated as a PDF?  File detection looks, sees that it is a ZIP file.  Presents same security threats as a PDF file.... need to check security model, probable threats?  embed VBScript?!  People could embed a ZIP file inside a GIF!   I N C E P T I O N  Java code executed in a JAR appended to a GIF.


 * http://bugzilla.wikimedia.org/28613: Normal NEW Some thumbnails [or squid cache of them] weren't purged when new version of file uploaded.
 * Think this is the related to issue that Tim said was too problematic to deal with before. (bug #?)
 * We pine for Tim
 * Mark to check in with Tim?


 * http://bugzilla.wikimedia.org/28087: Normal NEW Line breaks introduced when nesting nowiki within code tags.
 * another parsing bug? let Brion handle it


 * http://bugzilla.wikimedia.org/28626: High NEW JS syntax errors affect other modules in ResourceLoader
 * a celebrity bug, filed by Brion
 * high priority? or the highest priority?
 * Fix is to add a syntax checker into ResourceLoader?
 * in previous cases, minification broke, things became invalid -- these are fixed.
 * BUT if your code is bad in the first place, userscripts, gadgets, etc., no syntax checker in there!
 * is there a GPLv2-compatible JS validity checker that we can use as-is rather than creating one from scratch? (JSLint has the funky license.) put out the call, ask if one is out there -- ask wikitech-l??  Mark will do this
 * happy with high, been like this since 1.17 deploy. everything is working fine.... when you have a bad entry it kills you, makes it harder to debug... proper fix requires tweaking how resourceloader does some linking & minifying? check that there's a proper [?] in there [inaudible]

Open bugs for Mon, April 18

 * http://bugzilla.wikimedia.org/28439: Normal NEW Fatal Error if logged in
 * release related
 * Fatals are very common in the 1.16 version of LQT. You could poke Andrew about it but he's probably gonna say he's rewriting the whole thing anyway.


 * http://bugzilla.wikimedia.org/22014: High NEW Caching problems with mobile_main_page
 * Hampton says: The mobile site invalidates the homepage cache every couple hours. These really old pages have nothing to do with that. If you clear the mobile cache and start again... it *still* gives old versions.
 * fix assignee tomasz
 * related canonical URL redirection issue: https://bugzilla.wikimedia.org/27935
 * ^ that appears to be the actual cause, is now set as a blocker for 22014
 * ensure there is a canonical URL for every url
 * current code may be checking only the decoded URL, not the original encoded URL which is what Squid appears to be caching on. Thus, mismatches for '(' vs '%28'


 * http://bugzilla.wikimedia.org/25985: High NEW When $wgSpamRegex is triggered be sure to return to editing and not throw the users work away
 * Bug reported still there on March 7th
 * should be fixed, 1.18


 * http://bugzilla.wikimedia.org/23052: High REOPENED When inserting text in iframe mode (using toolbar, special characters or dialogs) the edit window scrolls
 * I verified this on WMF this past week.
 * Misfiled, but the described behavior is a bug
 * Needs a new bug created non-iframe, not scrolling related, existing bug should be closed.
 * Roan


 * http://bugzilla.wikimedia.org/25404: High NEW lucene search for simple text misses some results
 * Also see http://bugzilla.wikimedia.org/25586 Searching is not working on Korean Wikinews and others. Talked to rainman_sr... will do a search bug triage, but he doesn't have time to handle these.
 * Ops is aware, new search indexer will be set up soon. All should be fine in a few days


 * http://bugzilla.wikimedia.org/27982: Normal NEW deformed layout of ogg player options in new gallery
 * TheDJ sez This primarily requires deploy of r82181, r82215 and r82309
 * IIRC these revs are waiting on review from Trevor (who is sick) Kaldari
 * merge queue, poke trevor kaldari to review for 1.17


 * http://bugzilla.wikimedia.org/26063: High NEW Upload stash API allows some kinds of resource exhaustion
 * How much do we care?
 * Consensus is that this is low risk
 * It's actually unrelated to UploadWizard, it's been a vulnerability of the stash API since time immemorial. It is now slightly easier to trigger since mid-2010 or so, since you can now specify that a file should be stashed rather than just uploading a file with other characteristics that would trigger stashing.
 * We should make sure there's a garbage collection cronjob at least; ideally MW itself should do the GC periodically though.
 * NeilK asked for such a cronjob from ops recently but agrees MW app code is a good place to double check, at least setting per-user limits


 * http://bugzilla.wikimedia.org/26085: High REOPENED Languagelinks aren't working on talk pages
 * WONTFIX: See comments + http://bugzilla.wikimedia.org/28604


 * http://bugzilla.wikimedia.org/26123: Normal NEW Special:Undelete doesn't use ar_page_id
 * From Comment 3: Additional work will be needed after this bug is fixed to determine where (if anywhere) on WMF projects an OOO risk in history occurs.
 * non issue since we sort by time –Roan


 * http://bugzilla.wikimedia.org/28299: Highest NEW A file redirect from a foreign File Repo overrides local wiki page (instead of vice versa)
 * Security issue? WONTFIX?
 * Should Commons trump local wiki?
 * I bumped this from HIGHEST to HIGH as it's not breaking things wildly; but it might be a pain to workaround. --brion
 * Best decribed in #c2: https://bugzilla.wikimedia.org/show_bug.cgi?id=28299#c2
 * image page being created usually means a local description which supplements the Commons description, and would not affect the metadata or use of the image. Interpolating the redirect-target image when used as [[File:blah]] etc makes sense, unless the local image page *is itself* a redirect, or *actually has a local file* associated with it. [If it's _not_ affecting page views / editing it may not actually be an issue; if it is, those things need fixing.]


 * http://bugzilla.wikimedia.org/28359: Normal NEW diff radio buttons in revision history are not vertically aligned when "Justify paragraphs" is enabled
 * minor UI bug low priority


 * http://bugzilla.wikimedia.org/28485: Normal REOPENED "Block::purgeExpired" Database returned error "1205: Lock wait timeout exceeded;"
 * http://bugzilla.wikimedia.org/28543: Low NEW Article::updateCategoryCounts 1213 Deadlock found when trying to get lock
 * http://bugzilla.wikimedia.org/28499: Normal NEW 1205: Lock wait timeout exceeded; try restarting transaction (tracking)
 * bump up
 * Reedy's fix needs updating.
 * mark to ask Tim
 * Roan looked at this and saw it focused around a single user on a single wiki


 * http://bugzilla.wikimedia.org/28589: Low NEW Edit notices display "edit" tab instead of "view source" even if the editor cannot edit them
 * UI is inconsistant here
 * duplicated this today
 * looks like a regression


 * http://bugzilla.wikimedia.org/25885: High NEW IE upload fails silently on Enter key from wpDestFile
 * Still there? really?
 * Yup, this bug is still there, just checked. But who cares? The user is deliberately entering a blank filename (they have to first delete the pre-filled filename) and there are a zillion worse UI surprises that can occur on this page. Low priority, especially since we have a successor to this page
 * Actually not 100% sure that's what the user means-- assigning to myself to verify


 * http://bugzilla.wikimedia.org/28419: High NEW Replace MD5 password hashing with WHIRLPOOL
 * This would mean forward compatible password hashing improvements and future proofing
 * Tim had some plans for this, linked on bug
 * Why is this high priority?
 * presumably someone thinks salted md5 is too scary to keep using in production?
 * Let Tim set priority


 * http://bugzilla.wikimedia.org/28426: Enhancement NEW Remove stub link formatting user preference from MediaWiki core
 * This is more of an enhancement, and needs a more cache-friendly replacement to be developed.
 * diferent implementation would be more cache friendly
 * get some stats from wmf wikis (presumably fairly popular on small wikis). Roan's running it.


 * http://bugzilla.wikimedia.org/25394: Normal enhancement Configure which sections of the sidebar navigation menu are expanded/collapsed by default
 * Vector extension. Assigned to Trevor but Roan can take it too (or Timo?)
 * Shouldn't be too hard. Server side array with booleans passing to JS ? (if non-default)
 * Just use MediaWiki:Sidebar
 * Parsing the sidebar even more, perhaps wait untill the GUI Special:Sidebar thing is ready (GSoC) so we can store cleanly in db


 * [wmf] http://bugzilla.wikimedia.org/17316: Low ASSIGNED Redesign the wmf non-mediawiki 404 error page
 * Is this A MW bug? Can't admin's fix this? No
 * It's a shell issue, wasn't the shell triage on some other day? Priyanka
 * Issue is: ugly 404 handler page on Apache servers needs to be replaced with a non-ugly version. Not part of or served by MediaWiki.

Open bugs first discussed Mon, April 11

 * http://bugzilla.wikimedia.org/93: (REOPENED) [Normal] tilde signatures inside nowiki tags sometimes get expanded ( Nemo 22:04, 28 June 2011 (UTC) )
 * Two patches are available. See the last two comments. Which should be applied?
 * Brion says: there are some test cases, easy to add parser test cases, someone can test & give an update.
 * hexmode unhappy with Brion taking on too many bugs... good practice for someone else....
 * patch might mark off areas, & parse the rest of it
 * Neil K taking this bug just to lose my parser virginity
 * http://bugzilla.wikimedia.org/468: (REOPENED) [Low] Preceding text and single apostrophes are not included in links
 * Tim fixed Bug 15035 (http://bugzilla.wikimedia.org/15035 ) which evidently reopened this. Since we require PHP 5.1+ now, could we back out the fix for Bug 15035 to re-fix this?
 * Link Trail vs Link Prefix -- different. "lion"?
 * for Arabic & other languages, a prefix does the same things, "al" as an article... should it show up in a link?
 * either totally bogus or there's a legit issue
 * 15035 is about use of a combined American trail? unclear
 * Brion to investigate & report back
 * I.... _think_ this is a vague request to have a consistent link trail/prefix behavior regardless of language, which would be useful for multilingual sites. 15035 was apparently about a fairly generic link_trail_, which would still have no effect on link_prefix_. Probably a normalization of all this would be nice. I would say it's very low priority however, and could easily be bumped back into a "consider this for the new parser".
 * http://bugzilla.wikimedia.org/549: (NEW) [Normal] Incorrect parsing of table headings and cells on the same line
 * Tables act inconsistently, but if we fix this bug it'll probably mean a few bot fixes need to be made to problem articles.
 * headers only appear if they have the single line there? seems strange.
 * Bug report is saying you should get the same rendering for both of those examples, whether on the same line or separate lines
 * can we ask the bug reporter what is happening and whether it's still happening?
 * it is verified, say engineers
 * ping & get clarification, but this is low-priority. Mark to ping
 * http://bugzilla.wikimedia.org/845: (REOPENED) [Low], /bar should be equivalent to foo, bar (new use of "pipe trick")
 * People have been waiting on this forever and it looks like at least the Wiktionary people have recently pinged on it. I dicn't even know what the "pipe trick" was until reading http://en.wikipedia.org/wiki/Help:Pipe_trick which people have updated with the (vain?) hope of getting this fixed.
 * Mark to mark this low-priority enhancement.
 * http://bugzilla.wikimedia.org/1115: (NEW) [Normal] Newline as list item terminator is troublesome
 * http://bugzilla.wikimedia.org/1581: (NEW) [Normal] pre over multiple lines in lists
 * http://bugzilla.wikimedia.org/1584: (NEW) [Normal] Need method for multiparagraph list items, continuing  numbered lists, and assigning specific numbers to list items
 * http://bugzilla.wikimedia.org/9342: (NEW) [Normal] Allow one blank line in list environments
 * Another recurring theme. One person even gave Bug 25587 (http://bugzilla.wikimedia.org/25587 ) which suggested modifying the parser to resume a previously stopped list.  But I'm pretty sure explicitly starting and stopping lists (e.g. {# ... #}) would be a easier, less buggy solution to implement.
 * Many possibilities. Doubt any will be done with current parser.
 * Something to keep in mind for new parser.
 * Mark to tag as newparser so they can use them as tests.
 * http://bugzilla.wikimedia.org/3230: (NEW) [Normal] Leading spaces in block render incorrectly when block preceded by another
 * Seems differently wonky now. Not sure if it is right. See http://en.wikipedia.org/wiki/User:Simetrical/3230
 * Not something affecting a lot of pages, and funny edge case that works at the moment. Not high-priority in the current parser.
 * Mark to tag as newparser
 * http://bugzilla.wikimedia.org/9207: (NEW) [Normal] Single newlines sometimes create paragraphs
 * http://bugzilla.wikimedia.org/5718: (REOPENED) [Normal] Block element written inline splits multiline paragraphs
 * (Stale?) patch available. Might fix Bug 3230, too?
 * http://bugzilla.wikimedia.org/6200: (NEW) [Normal] Linebreaks are mishandled in and 
 * Seems related to above, recent 1.16 patch
 * http://bugzilla.wikimedia.org/9996: (REOPENED) [Normal] Multiline tags in lists should be output more intelligently
 * all of these are to keep in mind for the future -- Mark to tag as newparser
 * http://bugzilla.wikimedia.org/1319: (REOPENED) [High] doBlockLevels inserts pre-tags in a text created by an extension
 * Tim suggested a fix years (and years) ago but evidently no one has had the time to implement this.
 * Priority is probably low-ish. parser is messing with text output by extensions. Input comes from tag hook extension.  Linebreaks in pseudoHTML converted to tags in final output.  Reedy & Brion have discussed.  Effect of old Gabriel W. design decision.  Wanted output to be valid XHTML... had to do with block-level elements (Tim's full explanation is on the bug)
 * Potential for unexpected breakage of all extensions. Less than a day of work. Replace linebreaks with whitespace before submitting to the parser, then everything will work fine
 * We know about this problem, and should tell extensions who have this problem to use the workaround
 * Tim but low priority
 * [if it's not easy or breaks after all, leave it for new parser. low priority.]
 * http://bugzilla.wikimedia.org/3158: (NEW) [Normal] Automatic nbsp is inserted even into XHTML attributes, including style
 * http://bugzilla.wikimedia.org/12974:  (REOPENED) [Normal] The newline added to a template, magic word,  variable,  or parser function that returns line-start wikicode  formatting (*#:;)  causes unexpected parsing
 * Two cases where what should go in an attribute gets mangled in slightly different ways
 * not that hard to do correctly, nice to fix because of the ugliness that shows up in articles? but low-priority.  Worked like this for 5 years.  We can live with it.
 * Mark to tag as newparser
 * http://bugzilla.wikimedia.org/3695: (NEW) [Low] External URL syntax cannot handle square brackets
 * Encoding of [ inside an external URL shouldn't be needed. See http://en.wikipedia.org/wiki/User:MarkAHershberger/Bug_Examples
 * Seems weird we'd expect people to encode their brackets. Technically brackets are illegal in URLs, but allowed in some circumstances. Would be nice to improve this.
 * Who shall enhance the regex? And HOW?
 * vast majority of people are going to have trouble with brackets -- it happens often
 * Probably not that hard to do reasonably.... would be nice to fix, would help users. May blow up!
 * Robla is skeptical. Is this a reserved character anyway, in URIs?
 * Didn't catch -- what's our resolution wrt this? tag it "richtexteditor"?
 * Brion sez workaround: rich editor can escape your []s for you :D


 * http://bugzilla.wikimedia.org/4161: (REOPENED) [Normal] Blank lines at the top of an article should be ignored
 * Classic! "TeX is smart enough to treat consecutive blank lines as one; it would be nice if MediaWiki were that smart too."
 * It shouldn't create paragraphs for blank lines at the beginning.Not worth fixing in current parser, probably
 * Mark to tag as newparser


 * http://bugzilla.wikimedia.org/12019: (NEW) [Normal] ifexist function uses pagelinks table in lieu of better options
 * there's some complaint that it shouldn't be in whatlinkedhere ... we have to store it some other way? unclear.
 * This is not intended to be hijacked? .... related to
 * Mark to tag as newparser
 * Will be a bigger underlying issue that should be addressed; has to do with storage of page dependencies versus linking (which also implies a dependency). Relates issues with links in template.


 * http://bugzilla.wikimedia.org/13260: (NEW) [Normal] post expand size counted multiple times for nested transclusions
 * we get timeouts when trying to save changes
 * tim is already assigned and says wont fix
 * Wait till performance improvements somewhere else via HipHop or the like?
 * Mark to mark low-priority


 * http://bugzilla.wikimedia.org/14562: (NEW) [Normal] UNIQ key exposed
 * See also the UNIQ tracking bug: 26213
 * ignore UNIQ bugs because they won't exist in new parser?
 * text passes into a parser function, comes back changed, haunted
 * MediaWiki's fault? who knows!
 * Tim says: it's the fault of the syntax highlighter extension. we have established precedent that it's the parser's responsibility to check for strip markers...
 * in general, if this is an extension, then should the extension be fixed? depends on the bug.
 * if it's source highlighting that's enabled on most of our sites, then YES it should be fixed :)
 * bug 13474, SMW, we don't have to worry about that. 13620, same.  13459, core's fault? maybe not.
 * Unless extension authors is saying there's ... 14959, author is no longer complaining or has found a workaround, so, low-priority. Look at specific cases.
 * Mark to investigate further.


 * http://bugzilla.wikimedia.org/16768: (NEW) Wikitext in image captions displayed as plaintext
 * Not sure what reporters want. If you put wikitext inside a  then you should not expect to render?
 * Img captions are wikitext! Captions are currently used in 2 places: area under thumbnail, + alt attribute of image.  But scary place in parser to be doing complicated things like list processing
 * Mark to tag as newparser


 * http://bugzilla.wikimedia.org/18765: (NEW) Bold/italic markup handled differently depending on leading whitespace
 * Enhancement request.
 * Surprised.... detect whitespace, table tag
 * Mark to change to low-priority enhancement, tag newparser


 * http://bugzilla.wikimedia.org/21844: (NEW) DOM preprocessor barfs on headings inserted by parser functions
 * [discussion of semiotics of barfing]
 * Tim originally investigated.
 * Tim to investigate & report back


 * http://bugzilla.wikimedia.org/27972: (REOPENED) does not urlencode passed querystring
 * vaguely similar to the one with brackets?
 * Tim reopened it
 * Tim to investigate, possibly fix!

Open bugs first discussed Mon, April 4

 * http://bugzilla.wikimedia.org/25647 Check Thumbnailablity on TIFFs ASAP >Neil
 * http://bugzilla.wikimedia.org/23310 CentralAuth: global suppression does not suppress very well
 * Could use some major fixups. Brion will take a look and see what's going on
 * this is probably small
 * Another riff on the "Central Auth is evil" theme. http://bugzilla.wikimedia.org/19161
 * This is something that was opened in the very beginning of CentralAuth; we should think about this for the next generation version, know what our policies & requirement should be
 * Chad just rolled back one of these configuration variables that was introduced
 * Merge Chad's to REL1_17

Revision Delete Specials (will wait for Aaron, unless I get interest)
 * http://bugzilla.wikimedia.org/21279 Regular deletion of revisions deleted with rev_deleted breaks links in log entries
 * Brion will take a look -- immediate problem may be solveable but it's unclear how much scope creep has come in on this bug
 * we might need to break this up into several bugs
 * there's low-hanging fruit, but we right now have 3 disparate systems to clean up & merge together at some point: page deletion, oversight, & RevDel. Need to refactor.  RevDel has the most versatility, so the other two should be folded in.
 * Aaron: refactor deletion and get rid of archive table (wanted to do this for ages). Add deleted_page table (with a bit for hidden page titles). Page deletion can consist mostly of moving a record from page to deleted_page. Queries can return only live revs by JOINing on page. Make sure history merge tools exist, since Delete/Undelete will be whole-page only. Script needed to depopulate archive table by moving stuff to revision.
 * Maybe we can merge the Nuke extension (for deleting all, or a subset, of someone's contributions)
 * SpecialNuke uses Article::doDelete / FileDeleteForm::doDelete [1]

Extension Review for Deployment
 * Babel - parserfunction like replacement for 100s -language templates copied/maintained/translated accross wikis.
 * get away from templates -- get something more scalable in place
 * MW Next/Wiki 2.0 ?
 * deploying across wikis is hard!
 * Why/how ? What needs to change to allow deployment on wiki farms ? –Krinkle
 * Narayam - script input from browser
 * UI is very bad; we haven't decided to dedicate resources to fixing it. Give community some feedback on why the UI is bad. Trevor will give that feedback on wikitech-l today
 * problem is: extension only addresses one lang community, not generic enough (one language, but many wikis (all sister projects in that lang + Meta-Wiki/Commons)
 * Translate - (talk of using it on Meta-Wiki/Commons? commons does more fullpage templates)
 * Commons: For commons it wouldn't be used for license templates though as they're central at TWN via WikimediaLocalization already. More for help/documentation/guidelines (ie. fullpages)
 * https://bugzilla.wikimedia.org/28021
 * int-msg i18N part: Would be useful for CentralNotice/fundraising (instead of manually editing MW namespace or via CN interface)
 * perpage part: for multilingual wiki pages (instead of -js hack or subpages manual navigation, transclusion and ?uselang= preservation)

Yet-Another-High Priority List
 * [core] http://bugzilla.wikimedia.org/27537 When SVG file is broken, warn about that, instead of mime failure
 * -> Neil, normal priority
 * [core] http://bugzilla.wikimedia.org/16036 PAGESINCATEGORY inaccurate for template-populated deletion categories
 * looks like a pain to fix, kind of nasty. this really ought to work if possible. -- Brion
 * reported in 2008. Not a new issue.  Krinkle has verified that it's still happening.
 * synchronisation issue - doing link counts & populating the table
 * order jobqueue, effieciency ? (eg. adding/removing a
 * [core] http://bugzilla.wikimedia.org/6100 Allow different directionality (rtl/ltr) for user interface and wiki content
 * resource loader has fixed it, reverted by Tim
 * + argument: cross-wiki editors/vandalfighters having their uselang on English – Krinkle
 * [core] http://bugzilla.wikimedia.org/28299 An image redirect from a foriegn File Repo overrides local wiki page. > Brion

Open bugs first discussed Mon, March 29

 * https://bugzilla.wikimedia.org/14683 - Password reset appears to fail
 * (lowered priority but keeping it around)