https://www.mediawiki.org/wiki/Scrum_of_scrums/2018-07-25
= 2018-07-25=
== Callouts ==
* Fundraising campaigns
https://meta.wikimedia.org/wiki/CentralNotice/Calendar
* SREs! Reading Infra need advice on backporting a package (mapnik 3.0.20)
to Debian Stretch (https://phabricator.wikimedia.org/T200284 )
* 1.32.0-wmf.14 train blocked on
[https://phabricator.wikimedia.org/T200346 Failed
executing job: ThumbnailRender]
* EventLogging sanitization updated to work on Hive databases as well, [
https://wikitech.wikimedia.org/wiki/Analytics/Systems/EventLogging/Data_ret…
read all about it and the new unified Whitelist]
* Need help with https://phabricator.wikimedia.org/T199252 - Google has bad
cache for a bunch of pages on it.m.wikipedia.org, need someone who has
Google Webmaster Tools access for wikipedia.org domain to help address this.
== Audiences ==
=== Readers ===
==== iOS native app ====
* Blocked by:
* Blocking:
* Updates:
**Still wrapping up 6.0 release (
https://phabricator.wikimedia.org/tag/ios-app-v6.0-walrus-on-a-unicycle/)
==== Android native app ====
* Blocked by:
* Blocking:
* Updates:
**Wrapping up navigation prototypes for user testing.
==== Readers Web ====
* Blocked by:
** New service request: chromium-render/deploy
https://phabricator.wikimedia.org/T186748
*** We're not blocked but we are ready to help and eager to close out the
epic
* Blocking:
* Updates:
** Mobile website (MinervaNeue / MobileFrontend):
*** Page issues UI and instrumentation T191528 T197932 T197931
*** Other fixes and hygiene T193172 T188261 T199066 T197133 T190549
** Product and design at Wikimania
==== Readers Infrastructure ====
* Blocked by: Need advice from SREs on backporting a package (see callouts)
* Blocking: n/a?
* Updates:
** Maps:
*** Working on migrating test servers to Cloud VPS
*** Working with SRE (Gehel) on migrating all servers to Debian Stretch
*** Various grooming/triage and bug fixes
** MCS/PCS:
*** Working with Services to deploy mobile-html endpoints, add language
variant support to all endpoints
*** Working with Services, Reading Web on designing page previews for
Wikidata
==== Multimedia ====
* Updates
** SDoC: search prototype progressing
** SDoC: backend search patches getting merged
** SDoC: working through implications of (technical and community)
discussions from wikimania
=== Contributors ===
==== Community Tech ====
* Blocked by: Security review for TemplateWizard
* Blocking:
* Updates:
** GlobalPreferences are out, work and ready for you to use
==== Anti-Harassment Tools ====
* Blocked by:
* Blocking:
* Updates:
**
==== Editing ====
* Blocked by: None
* Blocking: Languages for Content Translator 2 implementation:
https://phabricator.wikimedia.org/T197075#4447456
** Updates: improving UI test coverage for VE; fixed VE regressions
**
==== Parsing ====
* Blocked by:
* Blocking:
* Updates:
No significant things to report. My laptop is having a problem, not
charging, researching issue.
==== Growth ====
* Blocked by:
* Blocking:
* Updates:
**
==== Language ====
* Blocked by:
* Blocking:
* Updates:
**
=== Audiences Design ===
* Blocked by:
* Blocking:
* Updates:
**
==== UI Standardization ====
* Blocked by:
* Blocking:
* Updates:
**
== Technology ==
=== Analytics ===
* Blocked by:
* Blocking:
* Updates:
** Updated EventLogging sanitization to work with both MariaDB and Hive
databases, see docs at
https://wikitech.wikimedia.org/wiki/Analytics/Systems/EventLogging/Data_ret…
** Filed the hardware request to host a smaller public Data Lake on our
cloud
** Follow-up from Kafka outage, testing to reproduce in labs, incident
report:
https://wikitech.wikimedia.org/wiki/Incident_documentation/20180711-kafka-e…
=== Cloud Services ===
* Blocked by:
* Blocking:
* Updates:
**
=== Fundraising Tech ===
* Blocked by:
* Blocking:
* Updates:
** Making good progress on the ingress scripts for EventLogging data from
banner and landing page impressions
** Experimenting with different ways to let donors from certain countries
opt in to emails
** More CiviCRM work to export and expunge donor data
** Responding to "interesting" results of today's full-scale test of card
processor's new API
=== MediaWiki Core Platform ===
* Blocked by:
* Blocking:
* Updates:
**
=== Performance ===
* Blocked by:
**
* Blocking:
**
* Updates:
** Need help with https://phabricator.wikimedia.org/T199252 - Google has
bad cache for a bunch of pages on it.m.wikipedia.org, need someone who has
Google Webmaster Tools access for wikipedia.org domain to help address this.
** Working on https://phabricator.wikimedia.org/T200346
=== Release Engineering ===
* Blocked by:
** 1.32.0-wmf.14 train blocked by [https://phabricator.wikimedia.org/T200346
Failed executing job: ThumbnailRender] (in callouts)
** SRE: [https://phabricator.wikimedia.org/T199489 helm test in production
k8s namespace]
* Blocking:
* Updates:
** Gerrit upgrade to 2.15.3 soon, will send an email, will want SRE
=== Research ===
* Blocked by: None
* Blocking: None
* Updates:
** Working on recommending missing articles based on translation pageview
predictions
=== Scoring Platform ===
* Blocked by:
** JADE storage discussion is headed back to TechCom with a proper RFC:
https://phabricator.wikimedia.org/T200297
* Blocking:
* Updates:
** Minor frontend improvements to wikilabels
*** Using OOUI alert and config instead of alert() and config()
=== Search Platform ===
* Blocked by:
* Blocking:
* Updates:
**
- Working on ES 6.3 upgrade: https://phabricator.wikimedia.org/T198067
- Fixed Polish analyzer, pending reindex:
https://phabricator.wikimedia.org/T186046
- Set up analysis for Malay & Indonesian, pending reindex:
https://phabricator.wikimedia.org/T196780
- Discussed potential approaches for using NLP in search:
https://phabricator.wikimedia.org/T193070
- Improved prefix URI param handling:
https://phabricator.wikimedia.org/T198318
- Working on Esperanto analyzer:
https://phabricator.wikimedia.org/T200099
- Working on Lexeme fulltext search:
https://phabricator.wikimedia.org/T196188
- Working on collecting click statistics for Wikidata completion search:
https://phabricator.wikimedia.org/T196186
- Working on query parsing refactoring:
https://phabricator.wikimedia.org/T185108
=== Security ===
* Blocked by:
* Blocking:
* Updates:
**
=== Services ===
* Blocked by:
* Blocking:
* Updates:
**
=== Site Reliability Engineering ===
* Blocked by:
** None
* Blocking:
** None
* Updates:
** Started Apache Traffic server experimentation
** Will start discussions to set the date for the next datacenter switchover
** grafana-admin to be removed.
== Wikidata ==
* Blocked by:
** None
* Blocking:
** None
* Updates:
** Work on Structured Lexicographical Data continues: improving the editor
interface, and adding Senses (
https://phabricator.wikimedia.org/project/view/2292/)
**
== German Technical Wishlist ==
* Blocked by:
* Blocking:
* Updates:
**
== Multi-Content Revisions ==
* Blocked by:
* Blocking:
* Updates:
**
== SoS Meeting Bookkeeping ==
* Updates:
** Is there an update on changing the meeting to an earlier time?
*** Meeting this week to discuss updates to the template and meeting goals.
*** After that, we'll move the meeting to 2 hours earlier.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
Following comments from last time that we need some more volunteer
+2'ers, I've filed multiple nominations for +2 rights in mediawiki/*:
* Eranroz: https://phabricator.wikimedia.org/T199866
* Huji: https://phabricator.wikimedia.org/T199867
* Jack Phoenix: https://phabricator.wikimedia.org/T199868
* Matěj Suchánek: https://phabricator.wikimedia.org/T199865
And also for AbuseFilter:
* Daimona Eaytoy: https://phabricator.wikimedia.org/T199869
Thanks,
- -- Legoktm
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAltO8WoACgkQUvyOe+23
/KIWoA//difbevorl3FFiTlexfdwWMszkQmye+hLYyGGHbUThVTx4bgplc+VTsON
D69Zbma8ydnpsgP0ZK0s6Vt1yCnGmobTGuCV99waPBfgeWqEskEK0vB8BWjXHwFU
9iwI6C/W1eEaiJPB62NVseR9MXE9oIOKEWk1HmNMmH/s42CZa592MNajtfsLYmAW
wFUOGTwavuwffs4bW6s5Q2WPj+mTWkN61SJICTNdV27vsxsrUPOGIv8uKLSCvGAR
Rxxv6TBvc+Xh9o8L+AFsQ67S8Bn+QoFuahXuWvytc+O7hEEBoKvPowcGskbcSEXX
hWtSIDcT5DzmyM88vKB9GCa21/rPFnEjjBr6l8IIWCeDSyhePrIiz6JhF7ZXNFub
GwLiyhUxDXsnaPULb7wMUlAiINP8jl6GxXClG0o71u81OlIReqsqzFKEBnhBMibQ
9Nz0NM92Zu3aoEkI/4CEyVSvGIsf3rTACWkCB3QQYRrtzTKkiLF40CoVYiSRbSiJ
tQJmCkjGVMFZonEGL/Svux7C3yecgOCcoryZgIo+SVf0MNRjSoaLbZlJrq9x0gup
6Zc1G/K+YcQZ8ZC62VriZ12s6vPKIQILsYkE3AVQCNmhvgQ5vpBPbDO9BUvcqhpV
6DfHExlf9sCRiTq9aiq/GFEehBeBms/5pNYprd62AJExflc+Mpc=
=srTo
-----END PGP SIGNATURE-----
Patch to remove: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/447629
In the course of writing more tests for OutputPage, I came across the two
methods addMetadataLink() and getMetadataAttribute() that didn't make sense
to me. After a bit of digging, I found they were added in 2004 (22f8c4ce)
to support output of Creative Commons and Dublin Core <link rel="meta">
tags. The only thing they do (compared to directly calling addLink()) is
for some reason setting rel="alternate meta" instead of rel="meta" for the
first link. I didn't find any reason why they should do that, but based on
a nearby comment I speculate it was to work around bugs in some UAs that
were around at that time.
The functionality of outputting these <link> tags was moved to extensions
in 2011 (27c3b22b), while the methods were left in core. Those extensions
(CreativeCommonsRdf and DublinCoreRdf) now call addHeadItem() directly. A
search found no other uses in core or extensions. Any callers could be
trivially changed to use addLink() or another method.
Legoktm points out that getMetadataAttribute() is marked public, and
therefore strictly speaking can only be removed via the deprecation
policy. (Although getMetadataAttribute() is really just a helper function,
and the actual public interface is addMetadataLink() AFAICT.)
Practically speaking, although they aren't hurting anything, I think this
is useless cruft that it's virtually certain nobody ever used, so I suggest
skipping the deprecation period in this case. Does anyone object?
Hello Everyone,
This is Jay. I have some questions and want to know that it is possible to
apply on the ground.
== Problems ==
* I work on the very trivial tasks. and even after working on the very
trivial tasks, sometimes my patch does not merge even after 6 months has
passed. Recently I have Abandoned my some patches due to be not merged
after 6 months has passed.[1][2]
* Recently there are many tasks created on phab to Archive the
extensions. Those
extensions have not maintained in the last 5 years.
* And also We have lack of peoples for reviewing those extension's patches,
which have not deployed on Wikimedia or any other big wiki.
== Potential Solution ==
The potential solution is to create a new group on the Gerrit with +2
rights. This group will manage those extensions which have not maintained
by the owner in last 1 year (if not, Maybe 2 years). This will save the
extension from being unmaintained. There are many users who have good
knowledge and They review patches like Mainframe98,[3] MGChecker, and
others.
So my question is why does we not create this type of group? so that users
can managed those extensions which have not maintained in last 1 year.
[1]
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/LanguageTag/+/40605…
[2] https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Arrays/+/405057/
[3]
https://gerrit.wikimedia.org/r/#/q/reviewedby:%22Mainframe98+%253Ck.s.werf%…
Thanks
Reminder: Technical Advice IRC meeting again **Wednesday 3-4 pm UTC** on
#wikimedia-tech.
The Technical Advice IRC Meeting (TAIM) is a weekly support event for
volunteer developers. Every Wednesday, two full-time developers are
available to help you with all your questions about Mediawiki, gadgets,
tools and more! This can be anything from "how to get started" over "who
would be the best contact for X" to specific questions on your project.
In addition to the weekly meeting at 3 pm, we will have an additional
meeting every first Wednesday of the month at 11 pm UTC, starting August
1st, 2018!
If you know already what you would like to discuss or ask, please add your
topic to the next meeting:
https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting
Hope to see you there!
Michi (for WMDE’s tech team)
--
Michael F. Schönitzer
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Thanks to all people involved,
I just read about this new video format in the making/released [0].
Of course, I am not asking to support this, as this seems like the future,
and not the present, but being a complete noob on video formats and codecs,
I would like to know if someone more knolegeble has some insight about this
and if it is something to keep in mind/someone has tested it and has
experiences to share/client and vendor support?
--
Jaime
[0] <url:
https://blog.mozilla.org/blog/2018/07/11/royalty-free-web-video-codecs/>
On Fri, Jun 29, 2018 at 6:46 PM, Brion Vibber <bvibber(a)wikimedia.org> wrote:
> Awesome sauce. Thanks Moritz!
>
> -- brion
>
> On Fri, Jun 29, 2018 at 7:39 AM Moritz Muehlenhoff <
> mmuhlenhoff(a)wikimedia.org> wrote:
>
> > Hi all,
> >
> > On Thu, Jun 28, 2018 at 01:54:18PM -0700, Brion Vibber wrote:
> > > Current state on this:
> > >
> > > * still hoping to deploy the libvpx+ffmpeg backport first so we start
> > with
> > > best performance; Moritz made a start on libvpx but we still have to
> > > resolve ffmpeg (possibly by patching 3.2 instead of updating all the
> way
> > to
> > > 3.4)
> >
> > I've completed this today. We now have a separate repository component
> > for stretch-wikimedia (named component/vp9) which includes ffmpeg 3.2.10
> > (thus allowing us to follow the ffmpeg security updates released in
> Debian
> > with a local rebuild) with backported row-mt support and linked against
> > libvpx 1.7.0.
> >
> > I tested re-encoding
> >
> > https://commons.wikimedia.org/wiki/File:Wall_of_Death_-_
> Pitts_Todeswand_2017_-_Jagath_Perera.webm
> > (which is a nice fast-paced test file) from VP8 to VP9, which results in
> > a size reduction from 48M to 31M.
> >
> > When using eight CPU cores on one of our video scaler servers, enabling
> > row-mt
> > gives a significant performance boost; encoding time went down from 5:31
> > mins
> > to 3:36 mins.
> >
> > All the details can be found at
> > https://phabricator.wikimedia.org/T190333#4324995
> >
> > Cheers,
> > Moritz
>
Hello,
The ArticlePlaceholder extension has QUnit tests run via nodejs. I am
trying to port them to Special:JavaScriptTest.
I am hitting a wall due to an OOUi widget not being found on the first
test. Most probably because the window is opened asynchronously and the
assertions are run before it opens.
JavaScript Promises are not my thing and I know nothing about OOUi. If
that is in your area of expertise, I could use a hand to finish up the port:
https://gerrit.wikimedia.org/r/#/c/444936/6
Thank you!
--
Antoine "hashar" Musso
Hi all,
It seems the Common.css on my website is pretty small but Resource Loader
loads it using a <link> tag in the head. I have read that it will be better
to instead inline the styles or even load them later.
What is the right way to go about this?
Any suggestions are welcome.
Also see
https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery
Regards,
Nischay Nahata