The Berlin Hack-a-thon (http://hexm.de/2o) and a variety of CSS-related bugs possibly caused by the recent IE fixes dominated the discussion durin this week's bug triage. Here's the bugs we discussed and a quick summary of the decided course of action.
== Bugsmash ==
* http://bugzilla.wikimedia.org/11415: __EDITPARENTSECTION__
I brought up this old enhancement request since it looks like it has a lot of people chiming in still.
It seems a little hairy, but would make a good candidate for our upcoming Berlin Hack-a-thon. (i.e. “bugsmash” tag)
* http://bugzilla.wikimedia.org/28819: Deleted revision links should use "rev_id" not "page/timestamp" * http://bugzilla.wikimedia.org/28820: Diffs using rev_id should work when one or both revisions are deleted * http://bugzilla.wikimedia.org/18104: Schema request change so deleted edits are identified by revisionID
Brion created thesee bugs which could each be resolved somewhat independently and suggested them for bugsmash in triage
* http://bugzilla.wikimedia.org/28829: Failure to subscribe to mediawiki-announce is not reported to the user
* http://bugzilla.wikimedia.org/28845: PostgresInstaller::canCreateAccounts() gives the wrong result
* http://bugzilla.wikimedia.org/20814: Enable $wgCrossSiteAJAXdomains for wikimedia sites
This isn't going to happen with the code as it exists right now. Tim has updated the bug with a comment outlining the problems and I asked him on IRC to create a new bug specifically addressing the problems that need to be addressed in MediaWiki before this can be done.
* http://bugzilla.wikimedia.org/28839: Interwiki may circumvent blacklist
Someone can do a SMOP that would find abusable interwiki links.
== CSS errors ==
* http://bugzilla.wikimedia.org/28891: Regression? Clicking on non-existing image link does not redirect to upload anymore * http://bugzilla.wikimedia.org/28840: Diffs not displaying correctly in IE because mediawiki thinks the … * http://bugzilla.wikimedia.org/28857: Sometimes there's "undefined" in a Resource loader CSS request
Tim said Roan probably has a patch for this particular bug. Need to get it applied (if it hasn't been already) and tested. I've emailed Roan.
* http://bugzilla.wikimedia.org/28851: Display problem on ku.wikipedia
This is likely be caused one of the other general CSS-breakage or RL-breakage issues. I'll recheck after the other CSS bugs (above) have been fixed.
== Other problems ==
* http://bugzilla.wikimedia.org/28889: out of memory error when deleting messages on commons
Fairly isolated since it only happens with a couple of specific messages on the Commons, which does a lot of customization. Lowered the priority but asked for other instances of the problem.
* 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
Translatewiki brought this one up because no one had been able to deal with it yet on IRC. We asked translatewiki for traceback and I assigned to dantman since he was working on this code.
* http://bugzilla.wikimedia.org/28842: user rights issue with vector and new editor
Tim is on top of this one and thinks it is an extension problem.
* http://bugzilla.wikimedia.org/28843: Customizable cite error
My description wasn't clear enough — asked Happy-Melon to help me clarify it.
On Mon, May 9, 2011 at 7:31 PM, Mark A. Hershberger < mhershberger@wikimedia.org> wrote:
http://bugzilla.wikimedia.org/28819: Deleted revision links should use "rev_id" not "page/timestamp"
http://bugzilla.wikimedia.org/28820: Diffs using rev_id should work when one or both revisions are deleted
http://bugzilla.wikimedia.org/18104: Schema request change so deleted edits are identified by revisionID
Brion created thesee bugs which could each be resolved somewhat independently and suggested them for bugsmash in triage
These are all related to the various issues that got mentioned in comments on bug 21279; I made some core updates on trunk yesterday which make Special:RevisionDelete act a bit more consistently with deleted page revisions that can be identified by a revision ID, thus generating more stable links in the logs:
https://bugzilla.wikimedia.org/show_bug.cgi?id=21279#c37
From there the idea of 'use the darned ar_rev_id value when possible' can be
spread out to other places, making things more and more convenient. :) Most of them should be pretty straightforward, or at least self-contained within a particular special page.
I do want to double-check on the deployment state though, since 18104 still mentions schema changing: do we have the ar_revid (ar_rev_id) index applied on archive table in production for all wikis, or are there any old ones that still need an index update? Without it these lookups will be hella slow, but based on the current behavior, previous code was already assuming that that was a clean lookup in the few places it was already being done.
-- brion
wikitech-l@lists.wikimedia.org