Hi,
On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote:
> We will be holding this brownbag in 25 minutes. The Bluejeans link has
> changed:
>
> https://bluejeans.com/396234560
I'm not familiar with bluejeans and maybe have missed a transition
because I wasn't paying enough attention. is this some kind of
experiment? have all meetings transitioned to this service?
anyway, my immediate question at the moment is how do you join without
sharing your microphone and camera?
am I correct thinking that this is an entirely proprietary stack
that's neither gratis nor libre and has no on-premise (not cloud)
hosting option? are we paying for this?
-Jeremy
Hello,
can someone to update list https://phabricator.wikimedia.org/P10500 which
contains repositories which haven't mediawiki/mediawiki-codesniffer.
I found in list that much repositories are empty, and repositories which
aren't available on Gerrit.
So, can someone please update this list of repositories (in
mediawiki/extensions) which haven't mediawiki/mediawiki-codesniffer, but at
least, contains one PHP file. or to provide me command with which I can
update list when I want, so I don't need to request it every time.
Best regards,
Zoran.
P. S.: Happy weekend! :)
Hi all!
Since the new Stable Interface Policy[1] has come into effect, there has been
some confusion about when and how the deprecation process can be accelerated or
bypassed. I started a discussion about this issue on the talk page[2], and now
I'm writing this email in the hope of gathering more perspectives.
tl;dr: the key question is:
Can we shorten or even entirely skip the deprecation process,
if we have removed all usages of the obsolete code from public
extensions?
If you are affected by the answer to this question, or you otherwise have
opinions about it, please read on (ok ok, this mail is massive - at least read
the proposed new wording of the policy). I'm especially interested in the
opinions of extension developers.
So, let's dive in. On the one hand, the new (and old) policy states:
Code MUST emit hard deprecation notices for at least one major
MediaWiki version before being removed. It is RECOMMENDED to emit
hard deprecation notices for at least two major MediaWiki
versions. EXCEPTIONS to this are listed in the section "Removal
without deprecation" below.
This means that code that starts to emit a deprecation warning in version N can
only be removed in version N+1, better even N+2. This effectively recommends
that obsolete code be kept around for at least half a year, with a preference
for a full year and more. However, we now have this exception in place:
The deprecation process may be bypassed for code that is unused
within the MediaWiki ecosystem. The ecosystem is defined to
consist of all actively maintained code residing in repositories
owned by the Wikimedia foundation, and can be searched using the
code search tool.
When TechCom added this section[3][4], we were thinking of the case where a
method becomes obsolete, but is unused. In that case, why go through all the
hassle of deprecation, if nobody uses it anyway?
However, what does this mean for obsolete code that *is* used? Can we just go
ahead and remove the usages, and then remove the code without deprecation? That
seems to be the logical consequence.
The result is a much tighter timeline from soft deprecation to removal, reducing
the amount of deprecated code we have to drag along and keep functional. This is
would be helpful particularly when code was refactored to remove undesirable
dependencies, since the dependency will not actually go away until the
deprecated code has been removed.
So, if we put in the work to remove usages, can we skip the deprecation process?
After all, if the code is truly unused, this would not do any harm, right? And
being able to make breaking changes without the need to wait a year for them to
become effective would greatly improve the speed at which we can modernize the
code base.
However, even skipping soft deprecation and going directly to hard deprecation
of the construction of the Revision class raised concerns, see for instance
<https://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg92871.html>.
The key concern is that we can only know about usages in repositories in our
"ecosystem", a concept introduced into the policy by the section quoted above. I
will go into the implications of this further below. But first, let me propose a
change to the policy, to clarify when deprecation is or is not needed.
I propose that the policy should read:
Obsolete code MAY be removed without deprecation if it is unused (or
appropriately gated) by any code in the MediaWiki ecosystem. Such
removal must be recorded in the release notes as a breaking change
without deprecation, and must be announced on the appropriate
mailing lists.
Obsolete code that is still used within the ecosystem MAY be
removed if it has been emitting deprecation warnings in AT LEAST
one major version release, and a best effort has been made to
remove any remaining usages in the MediaWiki ecosystem. Obsolete
code SHOULD be removed when it has been emitting deprecation
warnings for two releases, even if it is still used.
And further:
The person, team, or organization that deprecates code SHOULD
drive the removal of usages in a timely manner. For code not under
the control of this person, team, or organization, appropriate
changes SHOULD be proposed to the maintainers, and guidance SHOULD
be provided when needed.
Compared to the old process, this puts more focus on removing usages of obsolete
code. Previously, we'd often just wait and hope that usages of deprecated
methods would vanish eventually. Which may take a long time, we still have code
in MediaWiki that was deprecated in 1.24. Of course, every now and then someone
fixes a bunch of usages of deprecated code, but this is a sporadic occurrence,
not designed into the process.
With the change I am proposing, whoever deprecates a function also commits to
removing usages of it asap. For extension developers, this means that they will
get patches and support, but they may see their code broken if they do not
follow up.
Now, my proposal hinges on the idea that we somehow know all relevant code that
needs fixing. How can that work?
When TechCom introduced the idea of the "MediaWiki ecosystem" into the policy,
our reasoning was that we want to support primarily extension developers who
contribute their extensions back to the ecosystem, by making them available to
the public. We found it fair to say that if people develop extensions solely for
their own use, it is up to them to read the release notes. We do not need to go
out of our way to protect them from changes to the code base.
Effectively, with the proposed change to the policy, maintainers of public
extensions will get more support keeping their extensions compatible, while
maintainers of private extensions will receive less consideration.
It seems desirable and fair to me to allow for "fast track" removal of obsolete
code, but only if we create a clear process for making an extensions "official".
How exactly would an extension developer make sure that we know their extension,
and consider it part of the ecosystem? In practice, "known code" is code
accessible via codesearch[5]. But how does one get an extension into the
codesearch index? There is currently no clear process for this.
Ideally, it would be sufficient to:
* create a page on mediawiki.org using the {{Extension}} infobox,
* setting the status to "stable" (and maybe "beta"),
* and linking to a public git repository.
It should be simple enough to create a script that feeds these repos into
codesearch. A quick look at Category:Extensions_by_status category tells me that
there are about a thousand such extensions.
So, my question to you is: do you support the change I am proposing to the
policy? If not, why not? And if you do, why do you think it's helpful?
-- daniel
PS: This proposal has not yet been vetted with TechCom, it's just my personal
take. It will become an RFC if needed. This is intended to start a conversation.
[1] https://www.mediawiki.org/wiki/Stable_interface_policy
[2] https://www.mediawiki.org/wiki/Topic:Vrwr9aloe6y1bi2v
[3] https://phabricator.wikimedia.org/T193613
[4] https://phabricator.wikimedia.org/T255803
[5] https://codesearch.wmcloud.org/search/
--
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation
Hello all,
I am pleased to announce that the GitLab consultation is now open.
The open discussion period is set to run for 4 weeks, starting today.
Please see the consultation page for all of the details regarding how
the consultation will work:
https://www.mediawiki.org/wiki/GitLab_consultation
And the associated talk page where we welcome and encourage your engagement:
https://www.mediawiki.org/wiki/Talk:GitLab_consultation
Thank you,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Dir. Engineering Productivity A18D 1138 8E47 FAC8 1C7D |
Dear all,
We’re really happy to announce the second edition of the Coolest Tool Award
<https://meta.wikimedia.org/wiki/Coolest_Tool_Award>!
Tools play an essential role at Wikimedia, and so do the many volunteer
developers who experiment with new ideas, develop & maintain local & global
solutions and enhance the experience for Wikimedia communities.
There are incredible many great tools out there. It’s time to celebrate
this & to make the great work volunteer developers do more visible to
everyone :-)
The Coolest Tool Award ceremony will take place virtually this year, given
the current circumstances around events and travel. We will provide more
details soon about the specific logistics and dates.
The award is organized & selected by the *Coolest Tool Academy 2020*
<https://meta.wikimedia.org/wiki/Coolest_Tool_Award#Coolest_Tool_Award_2020>.
We plan to recognize the greatest tools in a variety of categories, for
examples you can look at last year’s categories
<https://meta.wikimedia.org/wiki/Coolest_Tool_Award/2019>.
As no one can possibly know all the cool tools out there, we’re looking for
some help & inspiration: Please point us to the tools that you think are
great - out of any reason you can think of!
Please use this form:
https://docs.google.com/forms/d/e/1FAIpQLSf5ZmXXamn9sRsagEiiZcUZDn1Ga0sF3Xm…
to recommend tools *by October 14, 2020*. You can nominate as many tools as
you want by filling out the form multiple times.
This survey will be conducted via a third-party service, which may subject
it to additional terms. For more information on privacy and data-handling,
see the survey privacy statement:
https://foundation.wikimedia.org/wiki/Coolest_Tool_Award_2020_Survey_Privac…
Thank you very much for your ideas & recommendation(s)!
We will continue to spread the word over the next 1-2 days, but if you get
the chance, please feel welcome to share this information with others too!
Thanks :-)
Joaquin, for the Coolest Tool Academy 2020
--
Joaquin Oltra Hernandez
Developer Advocate - Wikimedia Foundation
[crosspost from Maps-l]
Today the Wikimedia Foundation is announcing the deprecation of the public
API for Wikimedia map tiles. Around mid October the Foundation will end
support for the Wikimedia Maps Service API [1]. This change affects people
using Wikimedia maps on their own website or app. Maps on the Wikimedia
sites, in Wikimedia-hosted tools and gadgets, and on maps.wikimedia.org
won't be affected.
This decision was made based on recent outage incidents, primarily due to
spikes in third party usage, along with an analysis showing that more than
a third of maps provided are to non-Wikimedia services (including many to
for-profit organizations).
After the most recent incident [2], the service was limited so that only
cached maps tiles would be available. While this protected the servers, it
made the service unpredictable and highlighted the unsustainability of our
tile service. So, we have made the decision to discontinue the maps APIs
for non-Wikimedia users.
This change will allow our teams working on Maps to focus on the
sustainability of the maps used within Wikimedia projects.
You can follow the implementation of this change on Phabricator [3].
Best,
Erica Litrenta
[1] https://maps.wikimedia.org/osm-intl/
[2] https://wikitech.wikimedia.org/wiki/Incident_documentation/20200204-maps
[3] https://phabricator.wikimedia.org/T261424
--
Erica Litrenta
Manager, Community Relations Specialists
https://meta.wikimedia.org/wiki/User:Elitre_(WMF)
Hello,
This email contains updates for September 30, 2020. For the HTML version,
see: https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-09-30
Cheers,
Deb
------------------------
*= 2020-09-30 =*
== Product ==
=== iOS native app ===
* Updates:
** Released minor bug fix version [[phab:project/view/4831/|6.7.1]]
*** Widgets bugs/polish and Chinese variant fix
** In development on [[phab:project/view/4992/|6.7.2]]
*** Article as a Living Document experiment
=== Structured Data ===
* Updates: "beta" milestone for mediasearch
** A/B testing of the mediasearch algorithm in Special:Search on commons
showed a strong preference for the new search, so we're all v pleased about
that \o/
=== Abstract Wikipedia ===
* Updates:
** Voting in the
[[metawiki:Abstract_Wikipedia/Wiki_of_functions_naming_contest|community
naming contest]] for what to call the central wiki of functions is underway.
** Initial Vue rich editing interface has landed, with huge thanks to
Arthur P. Smith.
** Currently working on using ZType data to enforce structure when editing
ZObjects.
** Next up, converting the Vue editing interface into a hybrid view/edit
mode.
== Technology ==
=== Site Reliability Engineering ===
* Updates:
** Almost all services now behind TLS and the services proxy for talking to
each other. A minor outage for citoid, but otherwise going pretty well.
--
deb tankersley (she/her)
sr program manager, engineering
Wikimedia Foundation
I am happy to announce the belated availability of the general release of
MediaWiki 1.35!
Tarballs have already been uploaded, and the git tag has been pushed.
Thanks to everyone who helped out with this release, especially thanks to
those who tested out the release candidates and provided feedback, as well
as the developers who worked hard to get several important fixes merged in
time for the 1.35 final release. To see what's changed in 1.35, see the
release notes below.
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.3.19.
MediaWiki 1.35 is an LTS and is due to be supported until the end of
September 2023.
As a reminder, 1.31 is due to become end of life in June 2021. 1.34 is due
to become end of life in November 2020.
As per the pre-release announcement, 1.35.0 also includes some security
fixes that weren't in the release candidates, which came out yesterday for
the ther supported MediaWiki branches.
Known/outstanding issues:
* VisualEditor and Parsoid are now bundled in the tarball and no longer
need a separate Node.js service. The documentation for this still may still
require some updates. Please report any bugs [2] if this affects you.
* (T259685) Zeroconf (zero-configuration) VisualEditor/Parsoid doesn't work
using SQLite as the database backend for MediaWiki. This is due to the lack
of write concurrency in SQLite. If you wish to use this feature, it is
recommended to use MySQL/MariaDB rather than SQLite.
* Watchlist expiry (behind the $wgWatchlistExpiry flag) is currently still
experimental. It should become stable in a later point release. Please
report any issues/bugs [3].
== Security fixes ==
* (T232568, CVE-2020-25813) SECURITY: SpecialUserrights: If a viewer lacks
`hideuser`, ignore hidden users.
* (T255918, CVE-2020-25812) SECURITY: Unescaped message used in HTML on
Special:Contributions.
* (T256171, CVE-2020-25815) SECURITY: Unescaped message used in HTML within
LogEventsList.
* (T258763, CVE-2020-17367, CVE-2020-17368) SECURITY: Prevent invoking
firejail's --output functionality.
* (T86738, CVE-2020-25814) SECURITY: mediawiki.jqueryMsg: Sanitize URLs and
'style' attribute.
* (T115888, CVE-2020-25828) SECURITY: mediawiki.js: Escape HTML in
mw.message( ... ).parse().
* (T260485, CVE-2020-25869) SECURITY: ActorMigration: Load user from the
correct database.
* (T260485, CVE-2020-25869) SECURITY: ensure actor ID from correct wiki is
used.
* (T251661, CVE-2020-25827) SECURITY: TOTP throttle not enforced cross-wiki.
== Links to all mentioned tasks ==
* https://phabricator.wikimedia.org/T232568
* https://phabricator.wikimedia.org/T255918
* https://phabricator.wikimedia.org/T256171
* https://phabricator.wikimedia.org/T258763
* https://phabricator.wikimedia.org/T86738
* https://phabricator.wikimedia.org/T115888
* https://phabricator.wikimedia.org/T260485
* https://phabricator.wikimedia.org/T251661
=== Changes since MediaWiki 1.35.0-rc.3 ===
* (T261258) Remove checks for ancient ImageMagick versions in BitmapHandler.
* (T260232) Don't include null page ids in query list for category dumps.
* (T260009) Check existing watchitem when saving action=watch.
* (T259055) Correct success messages for action=watch.
* mediawiki.page.ready: Simpler tablesorter/makeCollapsible call.
* mediawiki.page.ready: Fix skin override config flags, wrong way round.
* (T262175, T248512) Remove requirement for ApiWatchlistTrait to be in
ApiBase.
* (T259053, T260434) Watchlist: Fix updateWatchLink removing css class when
action=watch.
* (T261901, T261476) mediawiki.notification: Don't close notif when
clicking <select> element.
* (T251506) Sanitizer: Truncate IDs to a reasonable length.
* (T259452) Parsoid updated to v0.12.0.
* (T261970) watch.ajax: Add expiry support to watchpage.mw event.
* (T262900) Fix failure of rebuildLocalisationCache.php due to
ResourceLoader hook.
* (T263014) Hard deprecate File::userCan() with $user=null.
* (T262547) Use localized success message after watching via action=watch.
* (T201491) Fix typo 'Watchlst' in `apihelp-edit-param-watchlistexpiry`.
* (T261081) Installer: consistently reset Language objects.
* (T250449, T250450) Installer: consistently reset Language objects.
* Explicitly wrap some XML calls in libxml_disable_entity_loader().
* (T262934) Ensure dropdown label is always on its own line.
* (T246855) resourceloader: Use a local HookRunner.
* (T263604) Have findBadBlobs.php require Maintenance.php rather than
cleanupTable.inc.
* (T263606) Set fake time, to avoid flaky tests.
* (T261325) Add FindMissingActors script.
* (T262364) shell: Don't blacklist /run/firejail.
* (T263655) NewPagesPager: Ignore nonexistent namespaces.
* Update specialPageAliases and magicWords for Egyptian Arabic (arz).
* (T261347) ParserOutput: don't throw on bad editsection.
* (T255918, CVE-2020-25812) SECURITY: Unescaped message used in HTML on
Special:Contributions.
* (T256171, CVE-2020-25815) SECURITY: Unescaped message used in HTML within
LogEventsList.
* (T258763, CVE-2020-17367, CVE-2020-17368) SECURITY: Prevent invoking
firejail's --output functionality.
* (T86738, CVE-2020-25814) SECURITY: mediawiki.jqueryMsg: Sanitize URLs and
'style' attribute.
* (T115888, CVE-2020-25828) SECURITY: mediawiki.js: Escape HTML in
mw.message( ... ).parse().
* (T260485, CVE-2020-25869) SECURITY: ActorMigration: Load user from the
correct database.
* (T260485, CVE-2020-25869) SECURITY: ensure actor ID from correct wiki is
used.
* Add Finnish special page aliases.
* Fix GuzzleHttpRequest request headers.
* Fix description for pruneFileCache.php.
* emptyUserGroup.php: handle more than 5000 users.
* Make ApiSandbox copyable URL absolute.
* (T261087) Add a link from a deleted page to that page's logs.
Open Bugs:
[1] https://phabricator.wikimedia.org/project/board/4035/
Bug report form:
[2]
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tags=MW-1.35-…
[3]
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tags=MW-1.35-…
**********************************************************************
Download:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.tar.gz
Download without bundled extensions:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.0.tar.gz
Patch to previous version (1.35.0-rc.3):
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.patch.gz
GPG signatures:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.0.tar.gz.…https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.tar.gz.sighttps://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.patch.gz.sig
Public keys:
https://www.mediawiki.org/keys/keys.html
Release Notes
https://www.mediawiki.org/wiki/Release_notes/1.35