====Collaboration====
* Blocking
** External Store work on Beta is back in our court. We'll resume soon.
* Blocked
** We've asked for a schema change for new Echo functionality. Ops has
started looking at this.
* Updates
** Echo MVC refactoring merged
** Some deletion fixes to core and Flow
Hi everyone,
We're planning on making today's RFC office hour[1] a triage meeting (at my
request). The agenda I'm planning to use is to (reasonably) quickly step
through the list of RFCs in the backlog column of the ArchCom-RFC board. A
wiki copy of this is posted on mediawiki.org[3], which I invite edits to
(albeit with the usual risk of edit conflicts).
The goal of this meeting will be to get through as many of the RFCs, where
I give a gut check for what the priority is, y'all tell me how wrong I am,
and then I set the priority.
For those of you that can't make it, don't sweat it. Nothing is set in
stone; Phab tickets are easy enough to edit. Furthermore, I'd like to
experiment with using a Phab Conpherence room for ongoing triage: Phab:Z425
[4]. Conpherence rooms are a bit more persistent than IRC conversations,
are cognitively cheaper to set up and use than mailing lists, and they
integrate nicely with Phab. If there's a comment about something we do in
the E187 meeting that you wish you had been there to make, and you don't
feel it's appropriate for a wikitech-l posting, the Z425 Conpherence room
is a great place to make your comment.
I'm looking forward to chatting with y'all!
Rob
[1] E187: RFC Meeting: triage meeting (2016-05-25, #wikimedia-office)
https://phabricator.wikimedia.org/E187
[2] #ArchCom-RFC board: https://phabricator.wikimedia.org/tag/archcom-rfc/
[3] Preliminary ordered list of items for triage:
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_triage_2016-05-25
[4]: https://phabricator.wikimedia.org/Z425
Hi all,
tomorrow, Thursday May 25th, I will be upgrading our HHVM servers to
use a recent version of the ICU[1] library, a long-needed change that
we are finally ready to perform: it allows us to stop maintaining an
older version by ourselves, including having to patch it for any
security issue.
For details about the rationale and the long process involved, see
https://phabricator.wikimedia.org/T86096
While the upgrade should be smooth, the ICU maintainers do not
guarantee backward compatibility for collation, so to be sure that is
addressed, we will need to run a maintenance script on all wikis that
have $wgCategoryCollation set to anything including with 'uca', see
https://phabricator.wikimedia.org/diffusion/OMWC/browse/master/wmf-config/I…
Since this script takes quite a long time to run[2], there will be
some user-facing effect, during the transition period, namely, citing
what MatmaRex says on the ticket:
"After ICU is upgraded, but before the updateCollation script
finishes, articles newly added to categories may appear out-of-order
on category listing pages. The headings on them might be wrong in
funny ways, too. Nothing else should be affected."
If no last-minute showstopper blocks the process, I will be starting
the procedure around 8:00 UTC, and log in the SAL[3] every step of the
process. Don't hesitate to contact me on IRC (#wikimedia-operations on
freenode, user _joe_) if you see some strange behaviour.
Thanks in advance for your patience
Giuseppe
[1] ICU stands for International Components for Unicode
[2] It is actually much, much faster to run now than it ever was,
thanks to the amaizing work others have done to improve it, see
https://phabricator.wikimedia.org/T58041 and
https://phabricator.wikimedia.org/T130692
[3] https://wikitech.wikimedia.org/wiki/Server_Admin_Log
--
Giuseppe Lavagetto, Ph.d.
Senior Technical Operations Engineer, Wikimedia Foundation
Dear readers of the Wikitech mailing list,
I am a member of the Wikipedia community and I have started a project to
reduce the environmental impact of the Wikimedia movement
<https://meta.wikimedia.org/wiki/Environmental_impact>. The main idea is to
use renewable energy for running the Wikimedia servers and the main reason
for this is that by doing so, Wikipedia can set a great example for
environmental responsibility in the entire internet sector.
My project was started after Greenpeace USA published a report
<http://www.greenpeace.org/usa/global-warming/click-clean/> about the
energy consumption of the biggest sites on the Internet in 2015 and in
which Wikipedia, to my astonishment, performed poorly, receiving a "D"
score and only passing because of the Wikimedia Foundation's openness about
its energy consumption.
I would very much like to change that and set up a page called "Environmental
impact <https://meta.wikimedia.org/wiki/Environmental_impact>" on Meta. I
have already discussed the issue with a few people both from the Wikimedia
Foundation's management and from the Wikimedia community and have received
positive responses.
In order to further advance the project, I would like to learn more about
how much energy Wikipedia's servers use. As far as I can tell, these
figures are not public, but I believe they could very well be.
Also, I am interested to learn how changing a server site's energy sources
can be carried out on the operations side since the United States energy
sector hasn't been completely deregulated yet.
So, thank you very much for any comments! Maybe there also is an even
better forum to discuss these questions?
Finally, if you would like to support my project, please consider adding
your name to this list
<https://meta.wikimedia.org/wiki/Environmental_impact#Show_your_support>.
Thank you.
Kind regards,
Lukas Mezger / User:Gnom <https://meta.wikimedia.org/wiki/User:Gnom>
TL;DR: AuthManager is now in core, although it's currently behind a feature
flag that is disabled on Wikimedia wikis. We're hoping that feature flag
can be removed from 1.27 before release. Help fix extensions!
AuthManager is a new authentication system for MediaWiki that allows for
easily plugging in multiple authentication methods, non-password-based
authentication methods (such as authentication by redirecting to a
third-party service), secondary authentication methods like two-factor
auth, and so on. We've[1] been working on it for over a year now, and it's
getting close to being done. Last week, we merged the core patches[2] and
fixes for extensions bundled in the tarball. These were also backported to
the REL1_27 branch. Documentation is now at
https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager,
please feel free to ask questions or to improve it.
AuthManager is currently behind a feature flag, $wgDisableAuthManager,
which can be set to use the old authentication system rather than
AuthManager. For Wikimedia wikis, our next step is to fix the rest of the
extensions we use,[3] then (gradually) enable AuthManager while making sure
things don't break.[4] We plan to default the flag to enabling AuthManager
in master soon,[5] and we hope to be able to remove it entirely from 1.27
before release.[6]
If you maintain an extension in Gerrit and it needs updating for
AuthManager, we've probably already filed a task in Phabricator for you!
Look at the subtasks of T110282 for extensions deployed on Wikimedia wikis,
or of T110291 for other extensions. Besides the information in the tasks,
we've also compiled a list of common things needing updating and some
solutions.[6]
If you run a wiki, you might need to set $wgDisableAuthManager = true if
you have extensions that break. Remember, though, this isn’t a permanent
solution, and you’ll need to update your extensions reasonably soon.
If you run a bot that still uses API action=login (and isn't using it for
BotPasswords), it's time to update! If you have an interactive application
that logs in with API action=login, you'll want to prepare to start using
action=clientlogin. If you want some visibility, the tracking task for
clients is T134945.
If you find bugs in AuthManager, please report them in Phabricator and
include the #Reading-Infrastructure-Team tag.
See also previous AuthManager announcements:
* https://lists.wikimedia.org/pipermail/wikitech-l/2016-January/084501.html
*
https://lists.wikimedia.org/pipermail/mediawiki-api/2016-January/003686.html
*
https://lists.wikimedia.org/pipermail/mediawiki-api/2016-January/003688.html
[1]: Mainly Gergő Tisza and I, with help from Bryan Davis and Chris Steipp.
[2]: https://gerrit.wikimedia.org/r/#/c/195297/,
https://gerrit.wikimedia.org/r/#/c/240052/,
https://gerrit.wikimedia.org/r/#/c/265201/, and
https://gerrit.wikimedia.org/r/#/c/282202/
[3]: https://phabricator.wikimedia.org/T110282
[4]: https://phabricator.wikimedia.org/T135504
[5]: We tried to do it already, but it broke all the selenium tests due to
changes to account creation. See https://phabricator.wikimedia.org/T135884
for progress on that.
[6]: https://phabricator.wikimedia.org/T135498
[7]:
https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager/Updati…
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
Hi everyone,
Here's the ArchCom RFC status update for 2016-W20 [1], which is also
available via mw:Architecture_committee/Status [2]
===== Recent RFC meetings =====
* ArchCom Planning meeting 2016W20: 2016-05-18: [[Phab:E183]] (E156/7)
** Notes: [[Architecture committee/2016-05-18]]
* ArchCom-RFC office hour 2016W20: 2016-05-18: [[Phab:E184]] (E66/35)
** [[Phab:T102476|T102476: RFC: Requirements for change propagation]]
===== Upcoming RFC meetings =====
* ArchCom Planning meeting 2016W21: 2016-05-25: [[Phab:E194]] (E156/8)
** Notes: [[Architecture committee/2016-05-25]]
* ArchCom-RFC office hour 2016W21: 2016-05-25: [[Phab:E187]] (E66/36)
** RFC triage meeting using [[phab:tag/archcom-rfc/|ArchCom RFC board]]
** Goal: assign priorities for items marked "needs triage" and ensure
that high priority items are clearly marked as such
===== Entering Final Comment Period =====
* None.
===== Recently Approved =====
* [[Phab:T120164|T120164 RFC: Institute "last call" period]]
==== RFC inbox ====
* [[phab:tag/archcom-rfc/|ArchCom RFC board]]:
** Inbox zero on 2016-06-11.
===== Shepherd status =====
* Brion
** (?)
* Daniel
** Software Quality working group?
** Working on Multi Content Rev Spec with Brion
** T113034 [[phab:T113034|RFC: Overhaul Interwiki map, unify with
Sites and WikiMap]]: (Update?)
* Gabriel
** Working with [[User:BSitzmann (WMF)|BSitzmann]] on
[[Phab:T132597|T132597]] (RFC: Agree on endpoints for feeds)
* Roan
** T108655 [[phab:T108655|RFC: Standardise JavaScript interfaces]]: I
need to start the second part, but the recent comments have me
confused. I'll need to talk to Timo and figure out what the subject of
part two should be.
* RobLa
** Still need to schedule an RFC triage meeting outside of ArchCom-RFC time
*** Filed [[phab:T135674|T135674]], and made it clear that I'm not
going to be able to do this without some help.
** Created [[phab:project/manage/2002/|#ArchCom-Approved Phab tag]]
([[Phab:T133803|T133803]])
* Tim
** Not many updates with cscott out of office. T89331 (Replace Tidy
in MW parser with HTML 5 parse/reserialize)
** T114444 [[phab:T114444|RFC: Introduce notion of DOM scopes in
wikitext]]: (Update?)
* Timo
** No update
===== No activity in the last two weeks =====
* T18691 [[phab:T18691|RFC: Section headings should have a clickable
anchor]] (Timo)
* T111588 [[phab:T111588|RFC: API-driven web front-end]] (Timo)
* T123753 [[phab:T123753|Establish retrospective reports for Security
and Performance incidents]] (RobLa)
* T122825 [[phab:T122825|Service ownership and minimum maintenance
requirements]] (Gabriel)
* T105766 [[phab:T105766|RFC: Dependency graph storage]] (Gabriel)
* T124504 [[phab:T124504|Transition WikiDev '16 working areas into
working groups]] (RobLa)
* T66214 [[phab:T66214|Use content hash based image / thumb URLs &
define an official thumb API]] (Brion)
* T91162 [[phab:T91162|RFC: Shadow namespaces]] (Brion)
* T128351 [[phab:T128351|RFC: Notifications in core]] (Brion)
* T122825 [[phab:T122825|Service ownership and minimum maintenance
requirements]] (Gabriel)
* T54807 [[phab:T54807|Identify and remove legacy preferences from
MediaWiki core]] (no shepherd)
* T88596 [[phab:T88596|Improving extension management]] (Daniel)
Our meeting for 2016-W21 (this coming Wednesday) will be a triage of
the ArchCom-RFC queue[3]
Rob
[1] ISO week 2016-W20: https://en.wikipedia.org/wiki/ISO_week_date
[2] https://www.mediawiki.org/wiki/Architecture_committee/Status
[3] https://phabricator.wikimedia.org/tag/archcom-rfc/