-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
I've written an RfC to introduce a standardized and recommended way
for re-distributors and packagers of MediaWiki to be able to tune
DefaultSettings.php as appropriate.
You can read more details on-wiki[1], and discuss it on Phabricator[2].
[1]
https://www.mediawiki.org/wiki/Requests_for_comment/PlatformSettings.php
[2] https://phabricator.wikimedia.org/T182020
Thanks!
- -- Legoktm
-----BEGIN PGP SIGNATURE-----
iQJLBAEBCgA1FiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlolpwQXHGxlZ29rdG1A
bWVtYmVyLmZzZi5vcmcACgkQUvyOe+23/KL43RAAld/PQ+KcmBks4lkaChAVK21o
7yTCBogPHQpLF73a4pNDIRn+XkHoO0jRmVkoGRIEsE4wTpvyFxxJo1cTbD2QAIKl
K0WKGBPQ8Lyyu4nFodiPwrvSGhhSi0iVvxMQPLq8K/FPF6bO8c331VAcLoJDQjyY
rfuQMnAnvBZ7kOzQPiXYgMkSpWgzFF1hn32h7HXyNuanK5KxjeRKl3ZTjmJj2iIk
zGoUhekJxipeIxgTb6ZT0H3YVMQdXyHuq4fvQFpOsX+KWgKspWOe4u7wbKTfCIN6
OCtRbIypHlSG4AgeQ1Bqcq3cPyvt2YuBaEaKn1ZMgByWKy65jcWt+x0KsVSe3aYm
jxzQI7gXBOIVvQeYHTezz91RSkL6bikI0wdBqg7Lsdr4Mb62CDQcfMmFSI1Iz8dD
ooz7Kcc7VTfU75VokJKNCPnVqdhux7dBgw5EhxBFGFIYfwUu6j8MayIxaZT8uyKj
OLCYOn8hslFEFeiOnSoMGtsS/6m6RR2YiTLC9r/+lGN2T/UeHm9RuCaBviZEaiQl
S9X9CAZlkaRg74zNyPO2e/E2v68F1shbpZDutzylal9QJfA0cEhBKbfQTEPlQwgN
qNxS7ajbb2G96HvF2Tyj8ai4YGENltmhp9M3/NzuJW6jj0fee+KNiNM7sRfMm7p4
nW7bXwXYkK4m4SuWxDM=
=PL+x
-----END PGP SIGNATURE-----
I've just now enable the feature flag on the testing wikis[1][2][3] that
allows MediaWiki to store comments longer than 255 bytes.
The web UI has not been updated to allow longer comments in places where it
enforces a limit, such as the edit summary box. But if you use the API to
edit, or perform page moves or do other things where long comments could be
entered and were truncated, you should now find that they're truncated at
1000 Unicode characters rather than 255 bytes.
Please test it out! If you find errors, or places in core features (not
comments in extensions such as SecurePoll, AbuseFilter, CheckUser, or Flow)
where *new* comments are still being truncated to 255 bytes, or places
where comments aren't showing up at all, please let me know. You can reply
to this message or post a task in Phabricator and add me as a subscriber.
If things go well, we'll look at rolling this out to production wikis once
the schema changes to the production databases are complete. See
https://phabricator.wikimedia.org/T174569 to follow progress there.
If anyone is interested in submitting patches for the web UI to reflect the
changed length limits, please do. I'll try to review them if you add me as
a reviewer.
[1]: https://test.wikipedia.org/wiki/Main_Page
[2]: https://test2.wikipedia.org/wiki/Main_Page
[3]: https://test.wikidata.org/wiki/Wikidata:Main_Page
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
For a while now, Wikimedia has been restricting the different binaries
that we shell out to (mostly image handling things) with firejail[1].
This was a manual process by writing wrapper scripts that invoked
firejail, and pointing MediaWiki to use those "binaries". It was a
pretty manual process, and other users of MediaWiki didn't benefit
from any of the work that was being done.
With [2], it's now possible to have MediaWiki invoke firejail with
restrictions specified in the code rather than configured separately.
For example, I converted the Score extension[3] to use the new shell
restrictions system.
There's more documentation available on-wiki[4]. You can test this out
yourself by installing firejail, and by setting
$wgShellRestrictionMethod = 'firejail';.
Note that firejail is a Linux-specific program, but the restriction
framework itself is abstract enough that it's likely that support for
other restriction software could be introduced.
[1] https://firejail.wordpress.com/
[2] https://gerrit.wikimedia.org/r/#/c/384930/
[3] https://gerrit.wikimedia.org/r/#/c/393830/
[4] https://www.mediawiki.org/wiki/Manual:Shell_framework#Restrictions
- -- Kunal / Legoktm
-----BEGIN PGP SIGNATURE-----
iQJLBAEBCgA1FiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlolpfoXHGxlZ29rdG1A
bWVtYmVyLmZzZi5vcmcACgkQUvyOe+23/KI8CBAApq8rMUGf0SKIPYCddyBLJgMO
vL02D6xjA0j1HCmxwynolUh751ZbAi+kgNbEA8gtosxfvQls++vs+V4x1OXfxFWJ
+Fz2Q0WYLv0j0o8pQPbugDknNlMljmILDf5ISxlCyGxw+i6bGLdFOuLWVWVTBsAx
eGlGLiFT6ROZfG72K/V0hgDnT760bwLHMVhBR672zo+Sau3UdY2hGu1uG/9GJbQv
50/9z2JtZs7ZrriqX240DZNSQwi8O7L4ppJRRUo+z+Apc4+QbxUgE0hgbe6RYKCg
K0qLksh2zZwW4c/5rqwq4P85hCS56JeW+++Wq1q7iapQH+PWsCWoztyDc0yZAp1P
+UVVSe9aOEAhudoU6yvoHlxlatAJGJv6H9LcyNHTPTAyKwYJtOc5u30PHMpt65mB
oVHu7KbSljkGTpnTd01d1VY2gLjil40FwjoL76M1LBxIPe1Fx9SFJVDgwXxpK1BM
gY0RcwWSXjzB+vnUOcQL6G4FQ/BYP9+43y4G3OtMTrkK8FkANaqgdpBECM7wJltl
lP6DGluQBBVv0cgXwZ+PKQg2dJkYxbWOR0m1T219REoP6O85EEZjvhyCx3IEaHGG
NAaTc5s93XR85hP4+gjdaC8lAJRIld4y3OjQQ7w4tWVygy7Ve4J/cYiRreWyTiBf
nRgXZj47aHrM92jY2q4=
=HIvI
-----END PGP SIGNATURE-----
Forwarding as engineering@ is rarely used anymore.
Thanks Timo.
----- Forwarded message from Timo Tijhof <ttijhof(a)wikimedia.org> -----
> Date: Fri, 1 Dec 2017 18:42:26 -0800
> From: Timo Tijhof <ttijhof(a)wikimedia.org>
> To: Engineering <engineering(a)lists.wikimedia.org>
> Subject: [Engineering] Wikimedia-log-errors summary - 2017-12-01
>
> Been a while since the last summary, so here is one.
>
> * 168 reported unresolved issues
> * 160 issues without an assignee
> * 10 issues tagged with "Patch-For-Review"
>
> Please check out the breakdown of open issues by project to see which
> errors in your field welcome fixing:
> <https://phabricator.wikimedia.org/maniphest/query/OunXBb3QsLmc/#R>
>
> Or get the latest straight from Logstash:
> <https://logstash.wikimedia.org/app/kibana#/dashboard/mediawiki-errors>
>
> Top 5 by hit count in last 24 hours:
>
> 1. ERROR channel=PageViewInfo "Failed fetching {url}: {error}"
>
> #PageViewInfo
> https://phabricator.wikimedia.org/T181011
>
> 2. ERROR channel=error "Fatal error: Call to exists() on a non-object"
>
> #ProofreadPage
> https://phabricator.wikimedia.org/T181868
>
> 3. WARNING channel=XMP "XMPReader::parse .. "
>
> #Multimedia #MediaWiki-File-management
> https://phabricator.wikimedia.org/T118799
>
> 4. WARNING channel=session "Metadata merge failed: {exception}"
>
> #MediaWiki-Authentication #CentralAuth
> https://phabricator.wikimedia.org/T158365
>
> 5. WARNING channel=session "Metadata has an anonymous user, but a non-anon"
>
> #MediaWiki-Authentication #CentralAuth
> https://phabricator.wikimedia.org/T181869
>
> -- Timo
> _______________________________________________
> Engineering mailing list
> Engineering(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
----- End forwarded message -----
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team Manager A18D 1138 8E47 FAC8 1C7D |
Hi,
The Technical Collaboration team proposes the creation of a developer
support channel focusing on newcomers, as part of our Onboarding New
Developer program. We are proposing to create a site based on Discourse
(starting with a pilot in discourse-mediawiki.wmflabs.org) and to point the
many existing scattered channels there.
This is an initial proposal for a pilot. If the pilot is successful, we
will move it production. For that to happen we still need to sync well with
Wikimedia Cloud Services, Operations and the Wikimedia technical community.
Please check https://www.mediawiki.org/wiki/Discourse and share your
feedback.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Am 01.12.2017 21:31 schrieb "Corey Floyd" <cfloyd(a)wikimedia.org>:
> Hi all,
>
> The experimental Trending Service[1] will be sunset on December 14th, 2017.
>
> We initially deployed this service to evaluate some real time features in
> the mobile apps centered on delivering more timely information to users.
> After some research [2], we found that it did not perform well with users
> in that use case.
>
> At this point there are no further plans to integrate the service into our
> products and so we are going to sunset the service to reduce the
> maintenance burden for some of our teams.
>
> We are going to do this more quickly than we would for a full stable
> production API as the usage of the end point is extremely low and mostly
> from our own internal projects. If you this adversely affects any of your
> work or you have any other concerns, please let the myself or the Reading
> Infrastructure team know.
>
> Thanks to all the teams involved with developing, deploying, researching
> and maintaining this service.
>
> P.S. This service was based off of prototypes Jon Robson had developed for
> detecting trending articles. He will be continuing his work in this area. I
> encourage you to reach out to him if you were interested in this project.
>
> [1] https://en.wikipedia.org/api/rest_v1/#!/Feed/trendingEdits
> [2]
> https://meta.wikimedia.org/wiki/Research:Comparing_most_
> read_and_trending_edits_for_Top_Articles_feature
>
>
>
> --
> Corey Floyd
> Engineering Manager
> Readers
> Wikimedia Foundation
> cfloyd(a)wikimedia.org
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi!
We are seeing more use of the Wikidata Query Service by Wikimedia
projects. Which is excellent news, but somewhat worse news is that the
maintainers of WDQS do not have a good idea what these services are,
what they needs are and so on. So, we have decided we want to start
tracking internal uses of Wikidata Query Service.
To that point, if you run any functionality on Wikimedia sites
(Wikipedias, Wikidata, etc., anything with wikimedia domain) that uses
queries to the Wikidata Query Service, please go to:
https://wikitech.wikimedia.org/wiki/Wikidata_query_service/Usage
and add your project there. That is both if your project runs queries by
itself on the background, or if it uses queries as part of user
interaction scenario.
We do not include labs tools currently unless it is absolutely vital
infrastructure (i.e. if it went down, would it substantially degrade the
main site functionality or make some features unusable?) If you still
feel we should know about certain lab tool, please leave a note on the
talk page.
What's in it for you?
We want to know these in order to better understand the scope of
internal usage and as preparation for T178492 (creating internal WDQS
setup) - with the goal to provide internal users more robust and more
flexible service. Also we want it to ensure we do not break anything
important when we do maintenance, and we know who to talk to if some
queries do not work as expected and we want to fix it.
What we want to know?
- We'd like to have general description of the functionality (i.e., what
the service is for)
- How to recognize queries run by it - user agent? source host? specific
query pattern? some other mark? It is recommended that it would be
possible to recognize
- What kind of queries it runs (no need to list every possible one of
course but if there are typical cases it'd help to see it)?
- How often the queries run - if it's periodic, or what is
expected/statistical usage of the tool if it's user driven tool?
- Where could we see the code at the base of it and who maintains it?
- Feel free to add any other information about anything you think would
be useful for us to know.
What was that page again?
https://wikitech.wikimedia.org/wiki/Wikidata_query_service/Usage
Thanks in advance,
--
Stas Malyshev
smalyshev(a)wikimedia.org
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2017-11): 317
Active Maniphest users (any activity) in (2017-11): 876
Task authors in (2017-11): 484
Users who have closed tasks in (2017-11): 272
Projects which had at least one task moved from one column to another on
their workboard in (2017-11): 283
Tasks created in (2017-11): 2314
Tasks closed in (2017-11): 1881
Open and stalled tasks in total: 36740
Median age in days of open tasks by priority:
Unbreak now: 15
Needs Triage: 338
High: 601
Normal: 821
Low: 1073
Lowest: 1018
(How long tasks have been open, not how long they have had that priority)
Active Differential users (any activity) in (2017-11): 29
TODO: Numbers which refer to closed tasks might not be correct, as
described in https://phabricator.wikimedia.org/T1003 .
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on phab1001 at Fri Dec 1 00:00:26 UTC 2017)