We would like to begin deployment of the 1.18 code base on Monday, but
we've fallen a little behind of where we need to be.

We want to have all code reviewed and all FIXMEs fixed by Friday night
so that we can enjoy the weekend, relax and prepare to push out the 1.18
code base to the first few wikis on Monday.

As of Thursday night, New York City time, we have 16 revisions left to
review and 4 FIXMEs left to fix.

More eyes on these problem revisions would help so here are the last 20
revisions that need work along with their committers and commit
summaries:

FIXMEs
==============
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86312 (reedy)
    We need a title object for parsing, do one against the message key

    Doesn't seem to be the best way, but it's the most applicable. If I
    abused $wgTitle, Chad would come and beat me too ;)

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86735 (reedy)
    Followup to r86312

    <ialex> Reedy: that rev is breaking usage of {{PAGENAME}} in
    messages, such as in MediaWiki:Noarticles

    Allowing optional passing in of a Title object (like it may be set
    in Message), but if it's not set, or not a title object, fall back
    and use $wgTitle (I'm sorry!)

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91518 (robin)
    (bug 6100; follow-up to r91315) Being bold and removing
    $wgBetterDirectionality (and dependent wfUILang) in core, as most or
    all work is finished.  Also:
    * Introduce classes mw-float-end, mw-float-start so we don't have to
      use inline css depending on wfUILang()/$wgLang (see HistoryPage
      and SpecialFileDuplicateSearch)
    * Add direction mark to protection log
    * Remove specialpageattributes as it is obsoleted by this commit
      (also fixes bug 28572)
    * Add two direction marks in wfSpecialList, which makes ltr links on
      rtl wiki (and vice versa) display nicely as well (only on those
      special pages however)
    * Revert r91340 partially: use mw-content-ltr/rtl class anyway in
      shared.css. Both ways have their [dis]advantages...
    * Set the direction of input fields by default to the content
      language direction (except buttons etc.) in shared.css

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91561 (bawolff)
    (Bug 19725) Do not include suppressed edits in the "View X deleted
    edits" message, and when doing prefix search of special:undelete.

    I'm not 100% sure this is the right thing to do, see the bug for the
    details. But basically this doesn't include an edit in the count if
    its text is hidden and its hidden from admins.  (Not sure if it
    should not be included only if everything is hidden). Its also weird
    to show people different things depending if they have suppress
    rights, without really indicating that.

    Minor db note: This causes the query to no longer use a covering
    index. I don't think that matters but just thought i'd mention.

    p.s. The upload page show deleted edits link is broken right now,
    (from before) I'll fix in a follow-up.



Needs Review:
==============

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84591 (aaron)
    * Made BeforeParserMakeImageLinkObj/BeforeGalleryFindFile let hooks
      set sha1 parameter
    * Made FlaggedRevs specify files by sha1,timestamp to handle renames
      with no redirects. This makes them handled as well as templates in
      this regard. (bug 27836)
    * Moved BeforeGalleryFindFile hook to proper place (don't trigger
      for non-NS_FILE titles)
    * Removed unused mRevisionId field from ImageGallery
    * Removed old hotfix from makeMediaLinkObj(); all the current
      callers would crash beforehand if the title was null anyway
    * Updated hook docs (some prior params were missing)
    * Broke some long lines and cleaned up some whitespace
    * TODO: track file info in core rather than fr_fileSHA1Keys and
      ugly, duplicated, queries.  This should be easy to do now.

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84610 (aaron)
    * Put parser output file version tracking to core
    * Added some ParserOutput accessors
    * A few cleanups to fetchFile()

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84619 (aaron)
    Follow-up r84610: removed fr_fileSHA1Keys and use core file version
    tracking instead.  Handles query spam FIXME in code.

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88780 (aaron)
    * Follow-up r88740:
    * Fixed parse() arguments in getRevIncludes()
    * Changed clearTagHook() to avoid preprocessed-xml cache corruption
    * Check current version cache in getRevIncludes()

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97022 (aaron)
    Possible fix for issue reported in r83762. I had a hard time
    confirming the problem/fix with profiling. Committing this now to
    get more attention.

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97077 (aaron)
    FU r97022: Fallback to empty array for getExtraSortFields() result
    in __construct() if no value is set for the sort order/type.

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97034 (brion)
    * (bug 6722) Spacing fixes for math functions with/without parens
    * (bug 18912) Add math support for \sen Spanish variant of \sin
    * (bug 18912) Fix spacing for \operatorname in math

    Reapplies r86962, r87117, r87936, r87941 plus some parser tests.

    Note that further batch testing to identify any other potential
    problems due to the spacing tweaks is a good idea!

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/74966 (catrope)
    First shot at porting Monobook to Vector. The only
    non-straightforward part is moving from a separate rtl.css file to a
    main.css file we can safely Janus. This is half-done right now.
    Notable things:
    * No longer including rtl.css, instead relying on Janused main.css
    * Renamed external.png to external-ltr.png so Janus will pick up on
      external-rtl.png (already exists)
    * Added @embed to all images, add @noflip where needed (may not have
      covered all cases)
    * Pulled some things from rtl.css into main.css such that they're
      no-ops in LTR but are needed in RTL. Example: body {
      direction:ltr;
    * Killed some RTL-specific rules in main.css that were superseded in
      main.css
    * Changed padding: 0 foo; to padding-right: foo; so it gets Janused
      right
    * Commented out loading of IE*Fixes.css. Still need to incorporate
      these into main.css somehow

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/96560 (catrope)
    OggHandler: Address issues with protocol-relative URLs. Live hack in
    r96400.
    * Use $wgExtensionAssetsPath instead of "$wgScriptPath/extensions"
    * Use wfExpandUrl() rather than the DIY method of detecting whether
      the URL needs expanding and prepending $wgServer. Left the
      detection for $wgCortadoJarFile alone since that needs $scriptPath
      prepended to it if it's not absolute
    * Expand $this->videoUrl using PROTO_RELATIVE instead of r96400 's
      PROTO_CURRENT to avoid cache pollution, and add a protocol the
      second the URL arrives on the JS side

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97150 (catrope)
    Update jquery.tablesorter for r97145: emulate <thead> if there is no
    <thead> in the HTML, by walking down the table starting at the first
    row and moving rows to the <thead> as long as all of its cells are
    <th>s (or the row is empty). Also fix and simplify the sortbottom
    code, which was incorrectly creating multiple <tfoot> elements if
    there were multiple sortbottom rows.

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92054 (diebuche)
    Render category links as an HTML list. Bug 12261. Based on patch by
    Thana & Bergi. It's removing the textual pipe separator, wrapping
    the links inside li elements and adding a left 1px border as
    separator. This makes it much easier to manipulate the list via JS
    or CSS and is also semantically correct

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89220 (platonides)
    Remove Cite singleton. Store it inside each associated parser at
    $parser->extCite This fixes bug 20748 and bug 15819 without breaking
    the other tests. Reverts r88971.  The conflict with CategoryTree was
    the old problem of a message being called inside of a parser
    callback, this time with clearState for which the hook is global.

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89706 (platonides)
    Reinstate r79122 (fix for bug 14404), reverting r83868. The real bug
    seem to have been r86131, fixed in r88902 (1.17) and r88902 (1.18).
    This is not merged with the r86131 change to
    Article::getParserOptions() since I don't see the point for the new
    function yet.  Reenabled its test ArticleTablesTest which was
    disabled in r85618

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86304 (reedy)
    * (bug 28532) wfMsgExt() and wfMsgWikiHtml() use $wgOut->parse()
    * (bug 16129) Transcluded special pages expose strip markers when
    they output parsed messages

    Also adding some related documentation during my travels around the
    code

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97192 (robin)
    Use wfSpecialList() so it displays properly when user direction !=
    content direction, and call Linker function statically.

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97145 (tstarling)
    Reverted r85922 and related: new doTableStuff(). I copied in the old
    doTableStuff() from before r85922 and reverted all parser test
    changes that looked vaguely related. Apologies to Platonides, since
    some of his parser tests appeared to be relevant to the old parser,
    but it's simplest to just revert all the related changes and then
    re-add any useful tests later.  See CR r85922 for full rationale.

_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to