I tagged a new release of Scap (3.15.0) yesterday, which will
hopefully be installed on the various servers next week. One of the
changes is that "scap sync" now gives and error, and directs the user
to use "scap sync-world" or "scap sync-file", depending on what they
meant to do.
This change was made because Release Engineering had noticed that
people accidentally run "scap sync" when they meant "scap sync-file".
We decided to have a "flag day" for this because merely warning
about using "scap sync" is very easy to miss, especially if in an
automated system somewhere. We also assume this is not actually used a
lot, and mostly interactively, in which case the error message is
hopefully clear enough to guide the user in the right direction.
We've fixed and are fixing places in scripts and CI jobs that we know
of where "scap sync" is used. If you find more, please report them to
Sorry about any inconvenience.
WMF release engineering team | he/him or they/them
"Imagine a world in which every single human being can freely share in
the sum of all knowledge."
Mailman, the software that powers our mailing lists, is extremely old, by
looking at https://lists.wikimedia.org/ you can guess how old it is.
I would really like to upgrade it to mailman 3 which has these benefits:
* Much better security (including but not limited to
* Much better UI and UX
* Much easier moderation and maintaining mailing lists
* Ability to send mail from the web
* Ability to search in archives.
* Ability to like/dislike an email
* List admins will be able to delete emails, merge threads, and much more.
* Admins won't need to store passwords for each mailing list separately,
they just login as their account everywhere.
* The current mailman stores everything as files (even mailing list
settings), mailman3 actually uses a proper database for everything meaning
proper backup and recovery, high availability and much more.
I have already put up a test setup and humbly ask you (specially list
admins) to test it (and its admin interface), if you want to become a list
admin, drop me a message. Keep in mind that we don't maintain the software
so the most I can do is to change configuration and can't handle a feature
request or solve a bug (you are more than welcome to file it against
Here's the test setup:
Here's a mailing list:
Here's an archive post:
Issues that I haven't figured out yet:
* This system has profile picture support but it's only gravatar which we
empty squares and looks bad. Reported upstream  but also we can have a
gravatar proxy in production. And in the worst case scenario we can just
inject "$('.gravatar').remove();" and remove them. Feel free to chime in in
the phabricator ticket in this regard:
* Upgrade will break archive links, making it work forever is not trivial
(you need write apache rewrite rule) (You can read about it in
* Mailman allows us to upgrade mailing list by mailing list, that's good
but we haven't found a way to keep the old version and the new ones in sync
(archives, etc.). Maybe we migrate a mailing list and the archives for the
old version will stop getting updated. Would that work for you? Feel free
to chime in: https://phabricator.wikimedia.org/T256539
* We don't know what would be the size of the database after upgrade
because these two versions are so inherently different, one idea was to
check the size of a fully public mailing list, then move the files to the
test setup, upgrade it to the new version and check how it changes, then
extrapolate the size of the final database. The discussion around the
database is happening in https://phabricator.wikimedia.org/T256538
If you want to help in the upgrade (like puppetzining its configuration,
etc.) just let me know and I add you to the project! It uses a stand-alone
puppetmaster so you don't need to get your puppet patches merged to see its
The main ticket about the upgrade: https://phabricator.wikimedia.org/T52864
Hope that'll be useful for you :)
I'm Rahul Pawar a B.tech second-year student at Visvesvarya National
Institute of Technology, Nagpur, India. I am a newbie but have tried
frontend mentor challenge, 2-star coder in Codechef, Gold medal in C, Cpp,
Python in hackerRank. I'm interested in working with this organization and
even participate in GSOC 2021. SO any mentor out there to guide me.
Thanks in advance.
This email contains updates for last week - August 19, 2020, with apologies
for the lateness.
For the HTML versions, see:
*= 2020-08-19 =*
== Product ==
=== Web ===
** '''Summary''': Vue.js-focused week.
** [[Reading/Web/Desktop Improvements|Desktop Improvements Project (Vector
*** [[phab:T258493|[Spike 8hrs] "Use Legacy Vector" is not working as a
*** [[phab:T258465|[Bug] Sidebar Expand/Collapse button impacted by Narrow
*** [[phab:T255727|Make collapsible sidebar persistent for logged-in users]]
*** [[phab:T249363|Move the existing search to the header in preparation
for Vue.js search development]]
*** [[phab:T251817|[Dev] Allow extensions to update the footer without
resorting to SkinTemplateOutputPageBeforeExec hook]]
*** [[phab:T244392|Vue.js search case study]]:
**** See [[Reading/Web/Desktop Improvements/Vue.js case study/Status
log|weekly status updates]].
** Mobile website (MinervaNeue / MobileFrontend):
*** [[phab:T260155|PHP Fatal error: Uncaught Error: Call to undefined
method TitleValue::isSubpage() in
on line 55]]
*** [[phab:T231160|HtmlFormatter incorrectly removes partial classname
matches in "xenomobile" or "not-an-navbox"]]
*** [[phab:T214647|[EPIC] Re-define the contract for displaying drawers and
overlays in MobileFrontend]]
*** [[phab:T212465|[EPIC] None of our View's should exhibit 2 levels of
*** [[phab:T258096|Regression: Nested references do not open if user clicks
on [ or ] (which are wrapped in span)]]
*** [[phab:T240622|[Technical debt payoff] Remove InlineDiffFormatter and
InlineDifferenceEngine from MobileFrontend]]
*** [[phab:T256520|Consider 'normalize' stylesheet RL module]]
*** [[phab:T259906|Add 'volumeUp' icon in OOUI]]
*** [[phab:T224985|Rename Special:ElectronPdf to Special:Download as Pdf or
Special:Export as Pdf]]
== Technology ==
=== Search Platform ===
* Blocked by:
* Updates ''(long list of updates, we were lagging behind in reporting
** Integrate Wikimedia Event Utilities with discovery-parent-pom -
** Search does not return exact title match -
** Querying WCQS should allow me to use prefixes for MediaInfo items -
** Gather statistics on head and tail query distribution on Commons -
** Slow indexing of Lexemes for wbsearchentities -
** Create spreadsheet of last 90 days of Commons search queries -
** Validate and fix TTL dumps of SDoC -
** Create a Examples Page for WCQS -
** v: prefix not correctly prefixed in Wikibase when using entitysource
config and extra prefixes -https://phabricator.wikimedia.org/T258507
** CirrusSearch throws an error on several wikis when searching for
** Access restriction for SPARQL Endpoint for Commons -
** UI for SPARQL Endpoint for Commons -
deb tankersley (she/her)
sr program manager, engineering
I'm pleased to announce the immediate availability of MediaWiki
1.35.0-rc.2, the third release candidate for 1.35.x, the next LTS version
to replace 1.31 which is due to go end of life in June 2021. Download links
at the end of the e-mail. The tag has been signed and pushed to Git.
Please note that the PHP version requirement has been raised from 7.2.9 in
MediaWiki 1.34 (and 7.0 in MediaWiki 1.31), to 7.2.22 (this may change
further, see below).
This is not a final release and should not be used for production websites.
Known issues are tracked in Phabricator on the release workboard . As
always please do try out the release candidate in a test environment and
report any issues that you discover. Please use the #MW-1.35-Release 
tag in Phabricator when reporting issues specific to this release.
It is expected that MediaWiki 1.35 will become final in late August 2020,
and will be supported for 3 years after that.
Known/outstanding issues/things to test:
* It has been proposed to require PHP 7.3 for MediaWiki 1.35, please
discuss at <https://phabricator.wikimedia.org/T257879>.
* Both the Vector skin and the underlying skin infrastructure are
undergoing numerous changes, so there might be things broken that are
already fixed in master and as such need backporting.
* VisualEditor and Parsoid are now bundled in the tarball and no longer
need a separate nodejs service. The documentation for this still needs to
be updated, and in some cases, users are reporting HTTP 500 errors from
* Watchlist expiry (behind the $wgWatchlistExpiry flag) is currently
experimental. It should be finished for the 1.35.0 final release.
* If you're on Windows and use 7zip and had issues in the previous release
candidates (and the last round of security releases) extracting the
tarball, this should be fixed for this release.
* While the rc.2 tarballs are smaller than the rc.1 tarballs, the patch for
rc.2 is much larger than usual, due to the removal of Gruntfile.js and
package-lock.json files from the tarball.
Changes since 1.35.0-rc.1:
* (T259693) uuid: Fix filenames on Windows.
* Remove Gruntfile.js and package-lock.json from the tarball.
* firejail: Strengthen by copying from Wikimedia's profile.
* (T260059) ResourceLoaderOOUIImageModule: loadOOUIDefinition() may return
* (T30162, T245387) The installer supports using a Postgres server running
on a custom port other than 5432.
* (T260201) Support private wikis in Parsoid zero configuration mode.
* Fix bad use of `|=` PHP bit operation where `= … ||` bool is intended.
* (T259212) SpecialBlock: Show error if a block could not be inserted or
* (T255842) UserOptionsManager: fix options reset.
* (T258649) WatchAction: avoid unnecessary UPDATEs when expiry is unchanged.
* (T250851) Allow skins to override mediawiki.page.ready initialisation.
* (T250851) mediawiki.page.ready: Allow skins to disable search lazy load.
* (T253135, T255632) Update language in watchlist expiry.
* Use IPset in MWRestrictions::checkIP.
* (T259564) Fix race condition on edit page.
* (T260759) Hide watchlist expiry label in edit form.
* mime: Fix docs of MIME_EXTENSIONS, they're arrays, not space-seperated.
* (T260031) Add application/font-sfnt to MimeMap for ttf files.
* (T259379) WatchedItemStore: Cache single WatchedItems with preexisting
* Add a maintenance script to create bot passwords.
* (T201269) Add Traditional Chinese zh-hant as fallback for Amis (ami).
* Improve wfParseUrl docs.
* (T251038) Add multi index fields in ImageListPager for unique paginate.
* (T259916) Guard against 'Widget not found' error.
Preliminary release notes:
Bug report form:
Download without bundled extensions:
Patch to previous version (1.35.0-rc.0):
this is to let you know that the "aphlict" service has been disabled on
Phabricator (for now) because it caused stability issues.
This means you will not get realtime (pop-up) notifications on Phabricator.
(If you had those enabled in the first place).
Regular notifications (that do not pop-up) and emails are not affected by
Daniel Zahn <dzahn(a)wikimedia.org>
Here are the minutes from this week's TechCom meeting:
== RFC: Drop support for database upgrade older than two LTS releases ==
* New RFC
* Moved from P1: Define to P2: Resource
* TT: The “UPGRADE” documentation file has a warning about upgrading
from certain older versions being unsupported. Maybe formalizing that in
some way would be useful. Interesting that the install is mentioned as slow
since it’s less than a second in CI as far as I know.
* DK: It’s hard to reason about database updates, so there’s mental load
involved. Unclear what to do with patches when changing database fields.
There was an idea that maintenance scripts would run after the schema
changes, but it doesn’t work in all cases, so now there are scripts that run
at different points in the process, which introduces additional complexity.
* TT: Right, running it mid-migration makes the state easier to reason
but falls apart if it runs dynamic MW code that can’t/shouldn’t support
on an old MW schema.
* DK: This is a question of MediaWiki as a product, which doesn’t have a
owner. Who has the authority to make this decision?
* TS: The people maintaining it are the most impacted, so it makes sense for
them to make the decision since it is related to developer productivity.
* TT: The RFC can help bring together different points of view on this, have
teams weigh in on the costs from their perspectives.
* TS: Two LTS releases sounds like a pretty short time compared to the
* DK: I think two is reasonable (four years). One cost is testability; it’s
test this update logic.
== Stable Interface Policy: Timeline for removing obsolete code ==
* Regarding a proposal to change wording on the talk page
* DK: The stable interface policy didn’t change the deprecation policy.
Things that aren’t used within the MediaWiki ecosystem don’t have to use
the deprecation policy. The intention was to make it easy to remove
obsolete code that isn’t used. So the question is if you make code
obsolete and then remove usages, can you remove it?
* TT: Hard deprecation is fine, not the same thing.
* DK: Depending on the interpretation of the policy, we could remove
anything if we remove all usages of it.
* TT: It’s meant to include a requirement to email wikitech-l with a notice
and justification. I think this made sense when there was an assumption
of stable by default. If we intentionally create an extension for public
I’m not sure why we’d need to bypass deprecation.
* DK: There should be a clear, easy path for getting something into the
* TT: Codesearch goes through external repositories as well. The process
for adding things to this isn’t easy or transparent, which needs to be
improved. The policy incentivizes the Wikimedia Foundation to make a
choice to help third party users migrate or continue support for some time.
As phrased now, the policy requires the code to no longer be used in the
default branch, allowing for the code manager to reject the change.
* TT: We can resolve within TechCom, but we should send a message to
== Introduce Authority objects to represent the user performing a given
* DK: Strawman design for managing permission checks with an experimental
patch. <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/582889/> There may
be resourcing available to start working on this in the next few weeks. We
could try to come up with a comprehensive design and submit an RFC or do
it the experimental way and use it in one corner of the codebase.
* TT: This is about making sure we can’t accidentally bypass permission
checks for non-current users. Experimenting seems fine, if there’s a
commitment to actively limit it to a narrow scope and not allow other
to adopt it.
* DK: The authority is something that actually encapsulates the checks
themselves, as opposed to a user. We’re missing a clean place to store
state for IP addresses when checking for IP-address blocks. Also applies
to OAuth sessions. This new idea partially supersedes permission manager,
so there’s some sunken cost there.
* TT: You might also want to talk to the AHT team about their experience
with Block Manager. Similar issues.
* DK: The tradeoff is more flexibility now and a commitment to clean it up
Thinking about this as example-driven development. Trying to think through
everything in advance tends to bring up important edge cases and problems,
but it tends to change again during implementation. The goal is to provide
more room for exploration and experimentation without losing the feedback
* TT: Needs an RFC to be used outside of the narrowly-defined, experimental
== Next week IRC office hours ==
No IRC discussion scheduled for next week
You can also find our meeting minutes at
See also the TechCom RFC board
If you prefer you can subscribe to our newsletter here