Hi,
I'm very excited to announce that Debian and Ubuntu packages for
MediaWiki are now available. These packages will follow the MediaWiki
LTS schedule and currently contain 1.27.1. If you've always wanted to
"sudo apt install mediawiki", then this is for you :)
For Debian users, you can get the mediawiki package for Jessie from the
official Debian repositories using jessie-backports, and it will be
included in the upcoming Stretch release.
Ubuntu users will need to enable a PPA for Xenial or Trusty to set up
the package.
Instructions, links, and help can all be found at
<https://www.mediawiki.org/wiki/User:Legoktm/Packages>. Please let me
know if you have any questions or feedback.
Finally, thanks to Luke Faraone, Faidon Liambotis, Moritz Mühlenhoff,
Max Semenik, Chad Horohoe, Antoine Musso, and all of the beta testers of
the package for making this a reality.
-- Legoktm
Hello!
Grrrit-wm[1] is an IRC bot that reports gerrit activiy to IRC. I've
been maintaining it for a few years now, but I no longer have the
bandwidth to do this. I'm going to remove myself as maintainer
shortly. It already has a bunch of people as maintainers on tool labs,
and anyone with +2 on mediawiki core can merge changes in it.
Hopefully that's all good enough :)
Thanks for all the fish!
[1] https://wikitech.wikimedia.org/wiki/Grrrit-wm
--
Yuvi Panda T
http://yuvi.in/blog
Hi, we need more voices and perspectives in the definition of the main
topics of the Wikimedia developer Summit 2017. Your participation is very
important!
RobLa went through the suggestions made and has proposed an organization
around main topics, and the discussion has started. Please check
https://www.mediawiki.org/wiki/WikiDev17/Topic_ideas and the discussion
page.
Rachel and I have decided to make a soft-launch of the Summit by opening
the registration and travel sponsorship requests only, because we cannot
keep postponing this step. You should hear news from us tomorrow.
We will launch properly opening the call for participation and promoting
the Summit widely in Wikimedia channels and beyond hopefully next week,
when we have a "good enough" list of main topics.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hey,
This is the 22nd weekly update from revision scoring team that we have sent
to this mailing list.
UI work:
- We configured the default threshold for the ORES review tool on
Wikidata to be more strict (higher recall, lower precision)[1]
- We fixed a display issue on Special:Contributions where the filters
would not wrap[2]
Increasing model fitness:
- We finished demonstrating model fitness gains using hash-vector
features[3]. Next, we'll be working to get the hash-vector features
implemented in revscoring/ORES[4].
- We implemented a new strategy for training and testing on all data
using cross-validation[5]. This will both increase the fitness of the
models and make the statistics reported more robust.
Maintenance and robustness
- We fixed an indexing issues in ores_model that prevented the
deployment of updated models[6].
- We did a minor investigation to a short period of degraded service
quality on WMF Labs[7]
1. https://phabricator.wikimedia.org/T144784 -- Change default threshold
for Wikidata to high
2. https://phabricator.wikimedia.org/T143518 -- Filter on user contribs has
nowrap, causing issues
3. https://phabricator.wikimedia.org/T128087 -- [Spike] Investigate
HashingVectorizer
4. https://phabricator.wikimedia.org/T145812 -- Implement ~100 most
important hash vector features in editquality models
5. https://phabricator.wikimedia.org/T142953 -- Train on all data, Report
test statistics on cross-validation
6. https://phabricator.wikimedia.org/T144432 -- oresm_model index should
not be unique
7. https://phabricator.wikimedia.org/T145353 -- Investigate short period of
ores-web-03 insanity
Sincerely,
Aaron from the Revision Scoring team
I assumed the same, but better be explicit about those assumption :)
On Thu, Sep 22, 2016 at 4:27 PM, Alex Monk <amonk(a)wikimedia.org> wrote:
> I had been assuming that puppetised crons were not really relevant...
>
> On 22 September 2016 at 15:19, Guillaume Lederrey <glederrey(a)wikimedia.org>
> wrote:
>>
>> Hello!
>>
>> Increasing visibility sounds like a great idea! How far do we want to
>> go in that direction? In particular, I'm thinking of a few of the
>> crons we have for Cirrus. For example, we do have daily crons on
>> terbium that re-generate the suggester indices. Those can run for >
>> 1h.
>>
>> My understanding is that those kind of crons should not be considered
>> scripts, but standard working parts of the system. Adding them will
>> probably generate more noise than useful information. Is this a
>> reasonable understanding?
>>
>> Thanks!
>>
>> Guillaume
>>
>>
>>
>> On Wed, Sep 21, 2016 at 12:29 AM, Greg Grossmeier <greg(a)wikimedia.org>
>> wrote:
>> > In an effort to reduce surprises and potential mishaps it is now
>> > required to include any long running tasks in the deployment
>> > calendar[0].
>> >
>> > "Long running tasks" include any script that is run on production 'work
>> > machines' such as terbium that last for longer than ~1 hour. Think:
>> > migration and maintenance scripts.
>> >
>> > This was discussed and proposed in T144661[1].
>> >
>> > Best,
>> >
>> > Greg
>> >
>> > [0] https://wikitech.wikimedia.org/wiki/Deployments
>> > Relevant diff:
>> > https://wikitech.wikimedia.org/w/index.php?diff=850923&oldid=850244
>> > [1] https://phabricator.wikimedia.org/T144661
>> >
>> > --
>> > | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
>> > | Release Team Manager A18D 1138 8E47 FAC8 1C7D |
>> >
>> > _______________________________________________
>> > Engineering mailing list
>> > Engineering(a)lists.wikimedia.org
>> > https://lists.wikimedia.org/mailman/listinfo/engineering
>> >
>>
>>
>>
>> --
>> Guillaume Lederrey
>> Operations Engineer, Discovery
>> Wikimedia Foundation
>> UTC+2 / CEST
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
>
> --
> Alex Monk
> VisualEditor/Editing team
> https://wikimediafoundation.org/wiki/User:Krenair_(WMF)
>
> _______________________________________________
> Engineering mailing list
> Engineering(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
--
Guillaume Lederrey
Operations Engineer, Discovery
Wikimedia Foundation
UTC+2 / CEST
Let me clarify the reasoning for the idea:
We realized that some schema changes (which used to be scheduled like other
deployments) no longer take 1 hour (they can take 1 month, running
continuously like https://phabricator.wikimedia.org/T139090 , because it
affects 3 of our largest tables). Also, they no longer requires read-only
mode or affect code in anyway (unless they are a prerequisite).
On the other side, a schema change, combined with high read or write load
from long-running maintenance jobs, like those of the updateCollation
script, or any other (those where just an example), could potentially make
lagging a worse problem: a single transaction has to store pending changes
during its lifetime, or long-running reads can block and create pileups due
to metadata locking. We want to avoid those, which certainly caused
infrastructure issues in the past.
So, in summary, regular deployments are exclusive from each others.
Long-running maintenance work could affect each other. This is a way for me
(and others) to have visibility of those potential negative interactions,
and make sure we can coordinate: "You are doing work on enwiki? No problem,
we will just run this task for commons". "you need to do an emergency data
recovery? I will wait to do this other task that can wait". Even if only
DBAs use it, it is already useful to not perform incompatible changes at
the same time. But it will be even more useful if everybody uses it!
On Thu, Sep 22, 2016 at 4:27 PM, Alex Monk <amonk(a)wikimedia.org> wrote:
> I had been assuming that puppetised crons were not really relevant...
>
> On 22 September 2016 at 15:19, Guillaume Lederrey <glederrey(a)wikimedia.org
> > wrote:
>
>> Hello!
>>
>> Increasing visibility sounds like a great idea! How far do we want to
>> go in that direction? In particular, I'm thinking of a few of the
>> crons we have for Cirrus. For example, we do have daily crons on
>> terbium that re-generate the suggester indices. Those can run for >
>> 1h.
>>
>> My understanding is that those kind of crons should not be considered
>> scripts, but standard working parts of the system. Adding them will
>> probably generate more noise than useful information. Is this a
>> reasonable understanding?
>>
>> Thanks!
>>
>> Guillaume
>>
>>
>>
>> On Wed, Sep 21, 2016 at 12:29 AM, Greg Grossmeier <greg(a)wikimedia.org>
>> wrote:
>> > In an effort to reduce surprises and potential mishaps it is now
>> > required to include any long running tasks in the deployment
>> > calendar[0].
>> >
>> > "Long running tasks" include any script that is run on production 'work
>> > machines' such as terbium that last for longer than ~1 hour. Think:
>> > migration and maintenance scripts.
>> >
>> > This was discussed and proposed in T144661[1].
>> >
>> > Best,
>> >
>> > Greg
>> >
>> > [0] https://wikitech.wikimedia.org/wiki/Deployments
>> > Relevant diff:
>> > https://wikitech.wikimedia.org/w/index.php?diff=850923&oldid=850244
>> > [1] https://phabricator.wikimedia.org/T144661
>> >
>> > --
>> > | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
>> > | Release Team Manager A18D 1138 8E47 FAC8 1C7D |
>> >
>> > _______________________________________________
>> > Engineering mailing list
>> > Engineering(a)lists.wikimedia.org
>> > https://lists.wikimedia.org/mailman/listinfo/engineering
>> >
>>
>>
>>
>> --
>> Guillaume Lederrey
>> Operations Engineer, Discovery
>> Wikimedia Foundation
>> UTC+2 / CEST
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
>
> --
> Alex Monk
> VisualEditor/Editing team
> https://wikimediafoundation.org/wiki/User:Krenair_(WMF)
>
> _______________________________________________
> Engineering mailing list
> Engineering(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
>
--
Jaime Crespo
<http://wikimedia.org>