Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Chad]

On Tue, Jan 22, 2019 at 4:05 AM Thiemo Kreuz 
wrote:

> > Fundamentally broken sounds like a bit of a stretch.
>
> A process that annoys people based on nothing but the fact that they
> happened to be the last one touching a file *is* fundamentally broken.
> This is not how anyone should look for reviewers, neither manually nor
> automatically.


It isn't? I figured "people who have worked on this code before" is an
excellent metric by which to find people to review your code. It's certainly
who I'd look to help me if I didn't just _know_ who to ask.


>
>
Here is a thought experiment: We could send review requests to the
> *least* active users that are still around, but *never* touched a
> file. The positive effects of such an approach include:
> * More people get familiar with the code.
> * Knowledge gets spread more evenly.
> * Bottlenecks and bus factors get reduced.
> * These people probably have more time.
> * Review requests are spread more evenly.
> * Workload is spread more evenly.
>
> Still sounds like a bad idea? Sure, because it is.


Dumb straw man.


> Now tell me: How is
> it more clever to do the *opposite* and dump review requests on people
> that have to much workload already?
>

Who said these people have too much workload? Just because they've
made a commit before? The blame attribution has zero insight into how
busy someone is.


> At this point I don't care any more if we are talking about a fully
> automated process or a suggest button. Both are targeting the wrong
> people.


>
> it was probably working quite well for our less-trafficked repositories.
>
> What is the difference between being the last one fixing a typo in a
> low-traffic vs. high-traffic repository? In both cases it's the wrong
> person.
>

If it's a low-traffic repository there's likely to be fewer overall
contributors.
Fewer contributors increases the likelihood of people being qualified to
review--whereas a high-traffic repo is more likely to have drive-by
contributor less capable.

And if it's just one-line typofixing it'd be ideal to exclude those from the
blame list--but we can't possibly know what was a one-line typofix and
what was a one line that saved us 50% of execution time on all pages.
At least not programmatically.

Honestly, if you think "people who've edited the code in the past" are a
poor
person to ask for review then you do not understand how code review works.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Chad]

Fundamentally broken sounds like a bit of a stretch.

In fact, it was probably working quite well for our less-trafficked
repositories. But the issues identified must be fixed and decent file
exclusion rules written before it goes back on for the active ones.

-Chad

On Jan 22, 2019 12:11 AM, "Thiemo Kreuz"  wrote:

> […] im adding that functionality to reviewers-by-blame.

I'm afraid I don't understand. Does this mean all the issues that make
the plugin send passive-aggressive, misattributed spam will still be
in place, possibly hitting peoples inboxes again any time somebody
decides it would be a good idea to turn this feature set on again? My
impression was more that all the ideas that have been shared in this
email thread describe an *entirely* different approach, following
entirely different ideas, with an entirely different UI, and entirely
different setup. What's the point of stuffing this into the same,
fundamentally broken codebase?

Sysops, please, for our sanity, do not let anybody enable this toxic
plugin again.


Best
Thiemo

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Chad]

On Fri, Jan 18, 2019 at 2:13 PM Pine W  wrote:

> I would like to suggest that this is the type of change that, when being
> planned, should get a design review from a third party before coding
> starts, should go through at least one RFC before coding starts, and be
> widely communicated before coding starts and again a week or two before
> deployment.


There was no coding to start--it's an upstream plugin.

One that I considered enabling ages ago, fwiw. I didn't because of the very
issues outlined in this thread.

There _must_ be a way to disable this for certain files. Great examples:

site.pp in puppet
en.json language file in MW core
CommonSettings or InitialiseSettings in wmf-config

All examples of files that are edited by dozens of folks. Folks who could
very well be unqualified to review your change and/or completely
uninterested in it at all.

I did enable the reviewers (not by blame) plugin ages ago. This allows
people to opt in with much more granularity (and would remove the need for
the bot)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] non-obvious uses of in your language

[Chad]

Found it :)

https://www.w3.org/MarkUp/SGML/sgml-lex/sgml-lex

Search for "empty comment declaration" :)

-Chad

On Fri, Oct 5, 2018, 11:50 PM Chad  wrote:

> I'm personally a fan of .
>
> I came across it years ago--it's a null comment. Can't find the reference
> at the moment though.
>
> -Chad
>
> On Thu, Oct 4, 2018, 2:25 PM Daniel Kinzler 
> wrote:
>
>> Am 04.10.2018 um 18:58 schrieb Thiemo Kreuz:
>> > The syntax "[[Schnee]]reichtum" is quite common in the
>> > German community. There are not many other ways to achieve the same:
>> >  or  can be used instead.[1] The later is often the
>> > better alternative, but an auto-replacement is not possible. For
>> > example, "[[Bund]]estag" must become "[[Bund]]estag".
>>
>> We could introduce new syntax for this, such as  or even .
>>
>> Or how about {{}} for "this is a syntactic element, but it does nothing"?
>> But if
>> that is mixed in with template expansion, it won't work if it expands to
>> nothing, since template expansion happens before link parsing, right? For
>> better
>> or worse...
>>
>> --
>> Daniel Kinzler
>> Principal Software Engineer, MediaWiki Platform
>> Wikimedia Foundation
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
On Oct 5, 2018 11:50 PM, "Chad"  wrote:

I'm personally a fan of .

I came across it years ago--it's a null comment. Can't find the reference
at the moment though.

-Chad

On Thu, Oct 4, 2018, 2:25 PM Daniel Kinzler  wrote:

> Am 04.10.2018 um 18:58 schrieb Thiemo Kreuz:
> > The syntax "[[Schnee]]reichtum" is quite common in the
> > German community. There are not many other ways to achieve the same:
> >  or  can be used instead.[1] The later is often the
> > better alternative, but an auto-replacement is not possible. For
> > example, "[[Bund]]estag" must become "[[Bund]]estag".
>
> We could introduce new syntax for this, such as  or even .
>
> Or how about {{}} for "this is a syntactic element, but it does nothing"?
> But if
> that is mixed in with template expansion, it won't work if it expands to
> nothing, since template expansion happens before link parsing, right? For
> better
> or worse...
>
> --
> Daniel Kinzler
> Principal Software Engineer, MediaWiki Platform
> Wikimedia Foundation
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] non-obvious uses of in your language

[Chad]

I'm personally a fan of .

I came across it years ago--it's a null comment. Can't find the reference
at the moment though.

-Chad

On Thu, Oct 4, 2018, 2:25 PM Daniel Kinzler  wrote:

> Am 04.10.2018 um 18:58 schrieb Thiemo Kreuz:
> > The syntax "[[Schnee]]reichtum" is quite common in the
> > German community. There are not many other ways to achieve the same:
> >  or  can be used instead.[1] The later is often the
> > better alternative, but an auto-replacement is not possible. For
> > example, "[[Bund]]estag" must become "[[Bund]]estag".
>
> We could introduce new syntax for this, such as  or even .
>
> Or how about {{}} for "this is a syntactic element, but it does nothing"?
> But if
> that is mixed in with template expansion, it won't work if it expands to
> nothing, since template expansion happens before link parsing, right? For
> better
> or worse...
>
> --
> Daniel Kinzler
> Principal Software Engineer, MediaWiki Platform
> Wikimedia Foundation
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Enforcing ORES limit of parallel connections per IP

[Chad]

Wouldn't it make to send a 429 instead of 408?

-Chad

On Sep 19, 2018 1:37 PM, "Amir Sarabadani" 
wrote:

Hello,
ORES has policy that no more than four parallel connections per IP should
be requesting the service. We weren't enforcing this policy and that caused
several outages before.

As of today if there is more than four connections per IP, the responses
after fourth one will be throttled and will be slower, and after seventh
connection, ORES just responds with immediate time out error.

This might affect CloudVPS and Toolforge users who connect to ORES from
there but there are several IPs coming from the cloud and looking at
request statistics, this limit is bigger than the usage. But if you are
having trouble using ORES in the cloud, let me know so I add those IPs to
the whitelist.

This limit only applies to external connections and it should not affect
internal requests coming from mediawiki or the change propagation service.

For more information, please read https://phabricator.wikimedia.org/T160692
and file a task against ORES project in phabricator in case anything is
wrong.

Happy scoring!
Best
-- 
Amir Sarabadani
Software Engineer

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/029/42207.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Chad]

On Wed, Aug 8, 2018 at 11:48 AM bawolff  wrote:

> So MZMcBride is temporarily banned for an unspecified amount of time.
> I have some concerns:
> a) The fact all these are secret is a recipe for FUD and
> misunderstandings. From accusations of partiality of the committee to
> people being unblocked because people think its an accident, are all
> natural consequences of things being secret. I think this is bound to
> create a negative environment in the long term.
>

This.


> b) What is the point of blocking him temporarily and not telling him
> how long he's banned for. That's just silly.
>

I'm going to quote someone out of context here, but I think it establishes
the point I'd like to make:

"temporary solutions have a terrible habit of becoming permanent, around
here"

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [MediaWiki-announce] MediaWiki 1.31.0 now available!

[Chad Horohoe]

Hello everyone,

I am happy to announce the availability of the general release of MediaWiki
1.31!

MediaWiki 1.31 includes all changes released in the smaller 1.31.0-wmf.*
software deployments to Wikimedia sites over six months, totaling over 2100
commits by roughly 130 unique authors. This is a very large release that
contains many new features and bug fixes. It is also an LTS release.

This is a summary of the major changes of interest to users and
administrators:
* https://www.mediawiki.org/wiki/MediaWiki_1.31

You can always consult the RELEASE-NOTES-1.31 file for the full list of
changes in this version.

Full release notes:
*
https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_31/RELEASE-NOTES-1.31
* https://www.mediawiki.org/wiki/Release_notes/1.31

**

Download:
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-1.31.0.tar.gz
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-core-1.31.0.tar.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-1.31.0.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-core-1.31.0.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

**

On a personal note, this will be the last release that I shall be handling.
As many probably know I left Wikimedia this month for a new career and as
such I won't have the time to dedicate to releasing MediaWiki anymore.
Whomever picks up the torch will do fantastic. See you all around the
Internet :)

-Chad
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [MediaWiki-l] git review warnings

[Chad]

On Tue, Jun 12, 2018 at 5:03 AM Martin Urbanec 
wrote:

> The second one is caused by Gerrit update. Upstream kept refs/publish/*
> working, because they know git-review is using that ref. I think that as
> soon as git-review developers fixes this and you will upgrade, the warning
> will disappear.
>
>
Yeah, I guess refs/publish/* is being deprecated.

Which is pretty funny, considering refs/for/* was going to be deprecated in
favor of the newer refs/publish/*. Later, that was deemed to be a bad idea
and so the new one was deprecated and the original retained.

Any scripts that use refs/publish/* should be updated. I assume git-review
will do this in short order.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

[Chad]

On Fri, Jun 8, 2018 at 7:02 AM Alex Monk  wrote:

> I think Gerrit admin permissions were abused to remove the review
>
>
https://gerrit.wikimedia.org/r/Documentation/access-control.html#category_remove_reviewer

Anyone who is a project owner on mediawiki/* could have done it, it had
nothing
to do with admin permissions. But that's not the point of this thread at
all...

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

[Chad]

On Fri, Jun 8, 2018 at 12:19 AM MZMcBride  wrote:

> Yaron Koren wrote:
> >That's how it went until two days ago, when Antoine Musso submitted a
> >patch for my Site Settings extension (I don't know why that one
> >specifically), re-adding the file. I rejected the patch, on the same
> >grounds as before, but another developer, Chad Horohoe, overrode me and
> >merged it in. That led to a discussion featuring Antoine, Chad, a few
> >other WMF developers, and me, which you can find here:
> >
> >https://gerrit.wikimedia.org/r/#/c/437555/
> >
> >Some of the (unbelievable) highlights:
> >
> >- From Antoine: "Well then can we just archive this repository please?"
> >
> >- From Chad: "Yeah no that's not how it works. If it's being hosted on
> >gerrit.wikimedia.org, it needs a CoC file. If you object to that, you can
> >find hosting elsewhere."
>
> It was really inappropriate for Chad to hastily and forcefully merge this
> change.
>
>
Probably. I was in a pretty crappy mood and I went "not again" and
merged it. I don't actually care one way or the other if repos have the
file (nb: I support the CoC), but I just want to be **consistent**

If we're gonna have them: have them everywhere. If not, then we
should be removing them everywhere.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [MediaWiki-announce] 1.31.0-rc.2

[Chad Horohoe]

Hi,

I'd like to announce the immediate availability of MediaWiki 1.31.0-rc.2,
the second release candidate for 1.31.x. Links at the end of the e-mail. The
tag has been signed and pushed to Git.

This is not a final release and should not be used for production websites.
There are several major outstanding bugs on the workboard. As always, please
do try out the release candidate in a test environment. It's how we find
bugs that didn't surface in initial development :-)

You'll likely notice that I went from rc.0 to rc.2 with this announcement.
This
was not an oversight. While rc.1 was tagged, signed, and built as a tarball,
prior to announcing it I noticed the version number still referred to rc.0.
Rather than confuse people, I decided to move forward with an rc.2. There's
only
a two commit difference between the tags. If using the patch files, you'll
want
to do it stepwise, moving from rc.0 to rc.1 then on to rc.2.

There have also been schema changes since rc.0, so you will need to run
update.php.

Full release notes:
https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_31/RELEASE-NOTES-1.31
https://www.mediawiki.org/wiki/Release_notes/1.31

**
Download:
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-1.31.0-rc.2.tar.gz
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-core-1.31.0-rc.2.tar.gz
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-1.31.0-rc.2.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-1.31.0-rc.2.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-core-1.31.0-rc.2.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-1.31.0-rc.2.patch.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

--
Chad Horohoe
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki and OpenID Connect

[Chad]

On Fri, May 4, 2018, 1:21 PM Adam Sobieski <adamsobie...@hotmail.com> wrote:

> With such features, we can envision allowing groups of users or admins to
> determine that certain articles require a verified account to edit.
>

Why would this be desirable?

-Chad

>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [MediaWiki-announce] MediaWiki 1.31.0-rc.0 now available

[Chad Horohoe]

Hi,

I'd like to announce the immediate availability of MediaWiki 1.31.0-rc.0,
the first release candidate for 1.31.x. Links at the end of the e-mail. The
tag has been signed and pushed to Git.

This is not a final release and should not be used for production websites.
There's several major outstanding bugs on the workboard. As always please
do try out the release candidate in a test environment. It's how we find
bugs that didn't surface in initial development :)

Full release notes:
https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_31/RELEASE-NOTES-1.31
https://www.mediawiki.org/wiki/Release_notes/1.31

**
Download:
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-1.31.0-rc.0.tar.gz

Core only, no extensions:
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-core-1.31.0-rc.0.tar.gz.sig

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-core-1.31.0-rc.0.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.31/mediawiki-1.31.0-rc.0.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

--
Chad Horohoe
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Ops] Changes to SWAT deployment policies, effective Monday April 30th

[Chad]

On Fri, Apr 27, 2018 at 12:42 PM Stas Malyshev <smalys...@wikimedia.org>
wrote:

> Hi!
>
> > The new policy asks the folks submitting patches to split up patches to
> > avoid bad intermediate states ahead of time.
>
> Thank you Tyler for the explanation! Which means this patch needs to be
> split into several patches? Giving the lower limit of the patches, this
> becomes kinda challenging - if this patch becomes, say, three commits,
> using figures from Gergo it is possible to apply it (without blocking
> whole SWAT window) only in ~27% of windows available. Given that many
> people can't use every window for timezone reasons, it may become tricky.
>
> I think we should reconsider how we do both of those things - if we're
> requiring splitting the patches, the limit should be considered
> differently - there's no point of performing the whole cycle of checks
> after merging each component of a multi-component patch, so maybe those
> should be counted differently. Though, of course, merging patches
> separately probably make it slower than before. If we additionally have
> limit of four - which is low even by current historic usage - I am
> concerned this will lead to long wait times and a backlog of patches
> which might then block other work.
>
>

I think we could do 4 "changes" in a SWAT, which could consist of a couple
of
individual commits?

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki 1.31 branch (and PHP versions)

[Chad]

Hi,

I meant to send this Tuesday but I forgot.

MediaWiki 1.31 has been branched from master! You should now see a REL1_31
branch where appropriate items should be backported to.

Core was branched at 69257de17fc899c447c9f1229b6ed319bc05d316.
All extensions & skins were branched from their respective masters at about
the same time as core. I plan to cut rc.0 sometime next week.

PHP versions
The current plan of action is to leave master as compatible with 5.5 for
now. This is because Wikimedia production isn't ready quite yet. This is
being tracked at T172165[0]. We will be moving the REL1_31 branch to 7.0+
as the required minimum version. Once production is ready, we'll
forward-port this change to master. It should be a little inconvenient, but
not too terribly bad (and notably, makes life less stressful for our SREs).
In the meantime, please do NOT introduce changes to master that require
7.0+ for core, vendor, or WMF-deployed extensions & skins. Doing so will
make me sad :(

Otherwise, great job on 1.31.x everyone! I'm rather pleased with what I'm
seeing so far. Check out the workboard[1] for ways you can contribute to
getting it wrapped up (and as always, tag issues with that tag if they
should absolutely block release).

Have a fantastic weekend!

-Chad

[0] https://phabricator.wikimedia.org/T172165
[1] https://phabricator.wikimedia.org/project/view/3011/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Dead Links

[Chad]

On Sun, Apr 1, 2018 at 4:43 PM <ad...@gunsense.xyz> wrote:

> hi, is this list active?
>
> there appears to be a dead link on the group page pointing to this list:
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> dead link:
> "You can also use the gmane web interface for reading AND posting to the
> list.
> http://news.gmane.org/gmane.science.linguistics.wikipedia.technical/;
>
>
I removed most of the information about Gmane.


>
> also, the welcome email from this list has confusing info:
> "send a message to the list by sending it to: wikitec...@wikipedia.org"
>
> and
>
> "To post to this list, send your email to:
> wikitech-l@lists.wikimedia.org"
>
>
Fixed the former address to use lists.wikimedia.org as it should. Probably
been well over a decade since someone looked at that. Good spotting!

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit login oddities

[Chad]

On Tue, Feb 13, 2018 at 10:27 AM Chad <innocentkil...@gmail.com> wrote:

> On Tue, Feb 13, 2018 at 7:39 AM Derk-Jan Hartman <
> d.j.hartman+wmf...@gmail.com> wrote:
>
>> Ah, this explains why i wasn't able to login... Really confusing..
>> Can't we set a varnish/apache/nginx/whatever rule or something to
>> overwrite older now broken cookie settings ?
>>
>> DJ
>
>
>>
>
> Got a fix in the works for this. It's affecting more people than I
> initially thought!
>
>
Just landed the fix for this. Visiting the login page should force the old
cookie to expire and let you login again :)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] What's making you happy this week? (Week of 11 February 2018)

[Chad]

On Tue, Feb 13, 2018 at 1:31 AM Gergo Tisza <gti...@wikimedia.org> wrote:

> The new  gerrit skin, which is kind of meh on desktop but responsive and
> thus actually useful on mobile. (And it's enabled with a cookie so I can
> use it on mobile devices and keep the old look on desktop.) Also the new
> non-Phabricator-based repo browser linked from it, which has a much more
> logical UI and it's crazy fast. Clearly a lot of love went into the
> upgrade, thanks Chad for working on it!
>
>
Thanks for the kind words Gergo. Gerrit is a vital part of our day-to-day
work around here, so making it useful to folks is always high on my todo
list.

Fun fact! The reason it works so nicely on mobile is actually a
self-serving desire by Gerrit devs to allow engineers to do code review
while on their commute to Mountain View ;-)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit login oddities

[Chad]

On Tue, Feb 13, 2018 at 7:39 AM Derk-Jan Hartman <
d.j.hartman+wmf...@gmail.com> wrote:

> Ah, this explains why i wasn't able to login... Really confusing..
> Can't we set a varnish/apache/nginx/whatever rule or something to
> overwrite older now broken cookie settings ?
>
> DJ


>

Got a fix in the works for this. It's affecting more people than I
initially thought!

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Gerrit login oddities

[Chad]

Hi,

Two quick things:

* First, we updated the cookie path for Gerrit to enable sharing
authentication with the new Gitiles repo browser--for most users this has
been transparent but a few people have reported problems with being able to
login. If this happens, try clearing out any cookies you have for
gerrit.wikimedia.org and try logging in anew.

* Second: if you use Lastpass for your password management...the update
last week seems to have added autocomplete="off" to the login form, which
makes the workflow for password managers a little annoying. I'll look into
this further.

<3

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Train halted - Cirrus and DB issues

[Chad Horohoe]

Hiya!

I halted the train this afternoon. tl;dr: I rolled wmf.20 to group1 and I
saw a huge spike in DB replag and Cirrus errors. Rolling back made them go
away!

There are tasks:
https://phabricator.wikimedia.org/T186765
https://phabricator.wikimedia.org/T186764

I think Eric/Stas already fixed the Cirrus bug. The other one was
temporally related, but I dunno about causally.

Needs more investigation if we want to roll forward tomorrow!

<3

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Gerrit upgrade - Friday 2/2

[Chad Horohoe]

Howdy Gerriters!

On Friday, I'll finally be upgrading Gerrit from 2.13.9 to 2.14.6. Going to
do this from 21:00–23:00 UTC.
It shouldn't take the full two hours, but hey it's Gerrit.

https://phabricator.wikimedia.org/T156120

<3

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWikiTestCase now validates @cover tags

[Chad]

On Fri, Dec 29, 2017 at 12:47 PM Kunal Mehta <lego...@member.fsf.org> wrote:

> MediaWikiTestCase will now verify[1] that @covers tags are sane when
> running normal PHPUnit tests. Previously PHPUnit would only verify
> that when it ran the twice daily coverage job, and fail if even a
> single one was wrong.
>
> This also affects extensions, even though we don't generate coverage
> reports for them yet[2]!
>
> If your tests extend the PHPUnit_Framework_TestCase class, you can
> just add "use MediaWikiCoversValidator" so the trait is invoked and
> will still validate @covers tags.
>
>
As a friendly reminder: if you don't need all the overhead of
MediaWikiTestCase (ie: you're writing actual unit tests that don't depend
on MediaWiki), it's encouraged to extend PHPUnit_Framework_TestCase
directly. It's wayy faster.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] First step for MCR merged: Deprecate and gut the Revision class

[Chad]

Considering the code just landed last night and a good number of us are
going to be gone for vacation--is rolling this out with the Jan 2nd deploy
a little aggressive? I'd love to see this sit on beta (with eyes on it) for
a little longer. Or a way to deploy to testwiki etc independent of major
sites?

The first deploy after a holiday break is already pretty exciting, and
rolling this out feels like something that could use a dedicated window.

(Otherwise, kudos to the MCR team for hitting this milestone)

-Chad

On Fri, Dec 22, 2017 at 2:27 AM Daniel Kinzler <daniel.kinz...@wikimedia.de>
wrote:

> Hello all!
>
> Addshore last night merged the patch[1] that is the first major step
> towards
> Multi-Content-Revisions[2]: it completely guts the Revision class and
> turns it
> into a thin proxy for the new RevisionStore service. The new code is now
> live
> on beta.
>
> This is our second attempt: The first one, on December 18th, thoroughly
> corrupted the beta database. It took us some time and a lot of help from
> Aaron
> and especially Roan to figure out what was happening. A detailed
> post-mortem by
> Roan can be found at [3].
>
> Anyway - this stage of MCR development introduces the new multi-revision
> capable
> interface for revision storage (and blob storage) [4]. It does not yet
> introduce
> the new database schema, that will be the next step [5][6]. While doing the
> refactoring, I tried to keep the structure of the existing code mostly
> intact,
> just moving functionality out of Revision into the new classes, most
> importantly
> RevisionRecord, RevisionStore, and BlobStore.
>
> Beware that with the next deployment (due January 2nd) the live sites will
> start
> using the new code. Please keep an eye out for any strangeness regarding
> revision handling. Adam greatly improved test coverage of the relevant code
> (thanks Adam!), but it's always possible that we missed some edge case,
> maybe
> something about archived revisions that were partially migrated from on old
> schema or something similarly fun.
>
> Exiting times!
>
> Cheers
> Daniel
>
>
> [1] https://gerrit.wikimedia.org/r/#/c/399174/
> [2]
> https://www.mediawiki.org/wiki/Requests_for_comment/Multi-Content_Revisions
> [3] https://phabricator.wikimedia.org/T183252#3853749
> [4] https://phabricator.wikimedia.org/T174025
> [5] https://phabricator.wikimedia.org/T174024
> [6] https://phabricator.wikimedia.org/T174030
>
>
> --
> Daniel Kinzler
> Principal Platform Engineer
>
> Wikimedia Deutschland
> Gesellschaft zur Förderung Freien Wissens e.V.
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] On InvalidArgumentException and user-facing errors

[Chad]

On Thu, Dec 7, 2017 at 12:24 PM Bartosz Dziewoński <matma@gmail.com>
wrote:

> On 2017-12-07 21:05, Chad wrote:
> > Yeah, and when you throw ErrorPageError deep enough in a code path, it
> can
> > explode on cli operations. I've seen this before.
>
> Indeed you did, you even fixed this bug a couple months ago ;)
> I'm pretty sure it's safe to use now.
>
> 25c3c061b51cbfe377ebb2decbe09f7db7bc7397
> https://gerrit.wikimedia.org/r/#/c/363660/
>
>
Hacked so as to not explode. But the whole thing is a mess still.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] On InvalidArgumentException and user-facing errors

[Chad]

On Thu, Dec 7, 2017 at 11:15 AM Bartosz Dziewoński <matma@gmail.com>
wrote:

> For "expected" exceptions, you can throw ErrorPageError or one of its
> subclasses, which is handled internally to produce a pretty user-facing
> error page.
>
>
Yeah, and when you throw ErrorPageError deep enough in a code path, it can
explode on cli operations. I've seen this before.

Our MWException handling is weird :\

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] On InvalidArgumentException and user-facing errors

[Chad]

On Thu, Dec 7, 2017 at 11:07 AM Daniel Kinzler <daniel.kinz...@wikimedia.de>
wrote:

> Am 07.12.2017 um 19:48 schrieb Chad:
> > Basically the short version is: exceptions should only be shown to users
> in
> > the situation of *actual software errors*. They're the exception, not the
> > norm. What we *should* do in such situation is log the error (at the
> > ERROR/WARNING/etc level as appropriate) and then gracefully fall back.
>
> I agree with the idea, but I'd like to point out that log-and-fall-back
> should
> *not* be the normal way to handle things, IMHO.
>
> Let's take for example an invalid title. If a user supplied an invalid
> title,
> they should get a helpful error. There is no reason to even log this,
> really.
> This should be done by code that expects to handle user input, and can
> involve
> throwing and catching exceptions, or be handled some other way.
>
>
We're on the same page here. It doesn't inherently need to be logged,
that's why I qualified it with "as appropriate." If it's something where
the user just typed something bogus, we should return a helpful error to
them and move on. And the emphasis in what you say here *really* needs to
be on CATCHING the exception. Throwing with no catch is what's evil :)


> Code that does not expect raw user input usually SHOULD thrown an
> InvalidArgumentException if it gets invalid input, though! Something went
> wrong,
> so we should fail fast & safe!
>
>
Indeed, I have no qualms with this. The point I'm making is on
user-generated actions.


> We should however improve how we show exceptions to users. We have "nicer"
> handling for MWException than for other exceptions. I can think of no good
> reason for this distinction - can't we do the nicer handling for all
> exceptions?
>
>
Because our exception handling code is crap. Nobody's had the cycles to
work on it. Volunteers welcome ;-)

MWException is *very* heavy weight, and sadly doesn't let us use native PHP
extensions that make more sense. InvalidArgumentException is descriptive,
MWException is not. And a MWInvalidArgumentException that extends
MWException just to be descriptive seems overkill.

In an ideal world: we don't need MWException at all, or else it becomes a
lightweight wrapper exception for any other type on demand. I'm thinking
something like

throw MWException( 'InvalidArgumentException' )

Who knows?


> The log-and-fall-back case should be quite rare, and be reserved for
> compatibility code - compatibility with old data, in particular. So
> perhaps the
> invalid title comes from the page or the pagelinks table - that's
> unexpected,
> but not impossible: someone may have fiddled with $wgLegalTitleChars,
> rendering
> once-valid titles invalid. So in that case, log-and-fall-back is the
> correct
> behavior.
>
>
Indeed. Not all bad behavior needs logging (or sometimes, just at a
DEBUG/INFO level because data is nice but yelling at log watchers is not).

Details all tbd, but I don't think you and I disagree here much at all :)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] On InvalidArgumentException and user-facing errors

[Chad]

Hi!

Recently it seems as though there's been a huge increase in the use of
exceptions within the MediaWiki ecosystem. That's perfectly fine.
Exceptions are fantastic and a standard part of any developer's toolkit.

However, there seems to be a trend in throwing exceptions for codepaths
that don't catch them prior to returning to the user. The one I'm calling
out in particular is InvalidArgumentException.

It seems as though some code paths that are relying on user-generated input
are throwing this exception. That's pretty evil. There's a couple of
reasons:
-  This just returns a generic 503 error to our users. They don't know what
went wrong and they're left wondering why and filing bugs.
- Due to our current logging setup, we don't do nice parameter grouping for
exceptions. This means that each one is reported on its own, and we don't
have an idea of the scale/severity of the problem. We need to fix this, but
it doesn't preclude us being more proactive.

Basically the short version is: exceptions should only be shown to users in
the situation of *actual software errors*. They're the exception, not the
norm. What we *should* do in such situation is log the error (at the
ERROR/WARNING/etc level as appropriate) and then gracefully fall back.

I don't think we need an RfC or anything formal here, just a little bit of
common sense :)

Tldr: if there's no such user "Foo", we shouldn't return an exception when
a user tries to perform an action on it. We should return a helpful error
message, log it, and fall back gracefully.

-Chad

PS: Now that I think about it, there's been a proliferation of
RuntimeException for the exact same thing.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] FLIF for Wikimedia

[Chad]

On Mon, Dec 4, 2017 at 10:34 AM Ruben Kelevra <ru...@vfn-nrw.de> wrote:

> > Sure, your suggestion avoids a lot of this. But the CPUs involved will
> > experience heavy load, both on the server as well as clients that need
> > to recode FLIF files via a JavaScript library first.
> FLIF is very fast to decode via JavaScript, and in general, as the
> example shown above, it takes just 1 second to decode and encode a
> medium size image as PNG with just one thread on a pretty outdated
> notebook with an unoptimized decoder and encoder. :)
>
> Try adding a FLIF to a website and test out if the website load anywhat
> slower with the FLIF ... at the small image sizes you get on articles,
> the performance impact is neglectable and comparable to loading a font
> file to the browser.
>
>
Requiring Javascript just to look at an image seems rather ridiculous to
me, fast or not. It's just...silly sounding. So my browser doesn't support
FLIF...you have to use JS to turn it into some format (PNG) that I can
understand...for what, minimal size savings on the order of a few KB? That
doesn't seem worth the complexity...

How does it fall back for users with Javascript disabled outright? How fast
is it on older hardware? How about mobile? Remember: not everyone has fast
desktops or laptops :)

It doesn't look like there's very much support in the authoring area
either[0]. So we'd have to encode all uploads to this format. Would we be
storing the original PNGs as well, similar to how we store video transcodes
in multiple formats? If so, there goes any space savings on WMF's end.

The fact that the Debian RFP for the encoder/decoder has stalled for almost
2 years isn't very promising... [1]

Considering there's effectively zero browser support (comments like
[2][3][4] and *especially* [5] are pretty discouraging) it just doesn't
seem worth it the technical maintenance to support it on our end.

Don't get me wrong, the format itself seems kinda cool, but I'd be very
hesitant to be a pioneer for a new graphics standard that nobody else seems
to want to pick up yet.

-Chad

[0] http://flif.info/software.html#graphics-software
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812761
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1240692#c6
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1240692#c8
[4] https://bugs.chromium.org/p/chromium/issues/detail?id=539120#c4
[5] https://bugs.chromium.org/p/chromium/issues/detail?id=539120#c11
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] AdvancedSearch beta feature now on Mediawiki

[Chad]

Actually, I went ahead and deployed that fix now.

I use Timeless and I want to use advanced search too :p

-Chad

On Wed, Nov 22, 2017 at 5:32 AM Birgit Müller <birgit.muel...@wikimedia.de>
wrote:

> The main issues with timeless skin are fixed and will be deployed in next
> weeks' train:
> https://phabricator.wikimedia.org/T181106
>
> Stas & Igal: Thanks for the reports!
>
> Birgit
>
>
> 2017-11-22 1:01 GMT+01:00 יגאל חיטרון <khit...@gmail.com>:
>
> > You are right. I just checked, vector works for me either. Thank you all.
> > Igal
> >
> >
> > On Nov 22, 2017 01:50, "Stas Malyshev" <smalys...@wikimedia.org> wrote:
> >
> > Hi!
> >
> > > Hello, Birgit. Unfortunately, I can't open a phab ticket, because I'm
> on
> > > mobile, and there is no way to upload a file to phabricator from
> mobile.
> > > So, I'll answer you here. I'm on Lollipop, use internal browser,
> timeless
> > > skin. I can't make a screenshot from this device, so I did it on
> another
> >
> > Likely there's a problem with timeless, see:
> > https://phabricator.wikimedia.org/T181106
> >
> > Vector works fine for me though. I guess that's why it's "beta" :)
> >
> > --
> > Stas Malyshev
> > smalys...@wikimedia.org
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
>
> --
> Birgit Müller
> Community Communications Manager
> Software Development and Engineering
>
>
>
>
> 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.
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Try out the commit message validator

[Chad]

On Tue, Nov 7, 2017 at 10:45 AM Faidon Liambotis <fai...@wikimedia.org>
wrote:

> On Tue, Nov 07, 2017 at 11:19:57AM -0700, Bryan Davis wrote:
> > We could probably add checks for some common ones if someone compiled a
> list.
> >
> > Running a full spell check would be difficult because of the number of
> > false positives there would be based on a "normal" dictionary. Commit
> > messages often contain technical jargon (maybe something to try and
> > avoid) and snippets of code  (e.g. class names like
> > TemplatesOnThisPageFormatter) that would not be in any traditional
> > dictionary that we could count on being on the local host.
>
> Debian's lintian (lint tool for packages) has a check for common
> typos/misspellings in its informational mode. The package ships with
> /usr/bin/spellintian which is a simple spellchecker that can run
> independently.
>
> The benefit of using spellintian over e.g. aspell is that it addresses
> the issues you already identified: a) it just identifies typos, not
> complaining on unknown words it doesn't know, b) it's been created from
> observing typos in source code and package descriptions in the wild, so
> it's tailored to technical jargon and their misspellings. It could be a
> good fit to git commit messages.
>
> That doesn't mean it's free of false positives though, so I wouldn't
> recommend to use it in a voting check in a CI pipeline.
>

Plus, you know, intentional misspellings:

"Fix misspelling of wikinedia -> wikimedia"

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [MediaWiki-announce] 1.28.x End of Life

[Chad Horohoe]

Hi!

It's November 2017, which means that the 1.28.x branch of MediaWiki has
reached the end of its life. Lets wish it the best as it moves off to the
great big code repository in the sky. All users are encouraged to upgrade
to 1.29.x which is the latest stable branch.

Note: 1.30.0 should be out by the end of the month, we've already branched
and are working on making sure the release is ready-to-go :)

--
Chad Horohoe
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Previous mediawiki version test wiki

[Chad]

No non-emergency deployments on Fridays, Saturdays or Sundays.
Monday could work.

-Chad

‪On Thu, Sep 21, 2017 at 7:15 PM ‫יגאל חיטרון‬‎ <khit...@gmail.com> wrote:‬

> I glad you say so. What about Friday?
> Igal
>
>
> On Sep 22, 2017 05:07, "Chad" <innocentkil...@gmail.com> wrote:
>
> > It wouldn't be hard to do at all, technically. I imagine it'd be
> something
> > like a test3wiki.
> >
> > Main thing to know is when do we cycle off of the old version? When the
> > version goes out on Tuesdays? That day's already pretty loaded for
> software
> > moving about...
> >
> > -Chad
> >
> > On Thu, Sep 21, 2017 at 1:25 PM Brian Wolff <bawo...@gmail.com> wrote:
> >
> > > Making your case here is probably best. The release engineering team
> are
> > > the people you probably have to convince, although of course anyone
> could
> > > potentially create such a wiki, in an unofficial way.
> > >
> > > Keep in mind that keeping an older version of the software running does
> > > introduce a maintinance burden, so you will probably have to convince
> > > people that it would be regularly useful and not just useful this one
> > time.
> > >
> > > --
> > > bawolff
> > >
> > > On Thursday, September 21, 2017, יגאל חיטרון <khit...@gmail.com>
> wrote:
> > > > Thank you. Sorry to hear this. Is there some place I can suggest this
> > and
> > > > explain why do I think it can be very helpful?
> > > > Igal
> > > >
> > > > On Sep 21, 2017 22:12, "Brian Wolff" <bawo...@gmail.com> wrote:
> > > >
> > > >> On Thursday, September 21, 2017, יגאל חיטרון <
> khit...@post.bgu.ac.il>
> > > >> wrote:
> > > >> > Hi. Sometimes after the week deployment I need to compare the new
> > > version
> > > >> > with the previous one, in some aspect. Is there a test wiki that
> > > always
> > > >> has
> > > >> > one version before the current?
> > > >> > Thank you.
> > > >> > Igal (User:IKhitron)
> > > >> > ___
> > > >> > Wikitech-l mailing list
> > > >> > Wikitech-l@lists.wikimedia.org
> > > >> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > >>
> > > >> No there is not. You can of course download old versions of the
> > software
> > > >> and setup your own wiki but that is a lot of effort.
> > > >>
> > > >> --
> > > >> bawolff
> > > >> ___
> > > >> Wikitech-l mailing list
> > > >> Wikitech-l@lists.wikimedia.org
> > > >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > > ___
> > > > Wikitech-l mailing list
> > > > Wikitech-l@lists.wikimedia.org
> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Previous mediawiki version test wiki

[Chad]

It wouldn't be hard to do at all, technically. I imagine it'd be something
like a test3wiki.

Main thing to know is when do we cycle off of the old version? When the
version goes out on Tuesdays? That day's already pretty loaded for software
moving about...

-Chad

On Thu, Sep 21, 2017 at 1:25 PM Brian Wolff <bawo...@gmail.com> wrote:

> Making your case here is probably best. The release engineering team are
> the people you probably have to convince, although of course anyone could
> potentially create such a wiki, in an unofficial way.
>
> Keep in mind that keeping an older version of the software running does
> introduce a maintinance burden, so you will probably have to convince
> people that it would be regularly useful and not just useful this one time.
>
> --
> bawolff
>
> On Thursday, September 21, 2017, יגאל חיטרון <khit...@gmail.com> wrote:
> > Thank you. Sorry to hear this. Is there some place I can suggest this and
> > explain why do I think it can be very helpful?
> > Igal
> >
> > On Sep 21, 2017 22:12, "Brian Wolff" <bawo...@gmail.com> wrote:
> >
> >> On Thursday, September 21, 2017, יגאל חיטרון <khit...@post.bgu.ac.il>
> >> wrote:
> >> > Hi. Sometimes after the week deployment I need to compare the new
> version
> >> > with the previous one, in some aspect. Is there a test wiki that
> always
> >> has
> >> > one version before the current?
> >> > Thank you.
> >> > Igal (User:IKhitron)
> >> > ___
> >> > Wikitech-l mailing list
> >> > Wikitech-l@lists.wikimedia.org
> >> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >>
> >> No there is not. You can of course download old versions of the software
> >> and setup your own wiki but that is a lot of effort.
> >>
> >> --
> >> bawolff
> >> ___
> >> Wikitech-l mailing list
> >> Wikitech-l@lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] HHVM vs. Zend divergence

[Chad]

On Tue, Sep 19, 2017 at 10:50 AM C. Scott Ananian <canan...@wikimedia.org>
wrote:

> Chad: the more you argue that it's not even worth considering, the more I'm
> going to push back and ask for actual numbers and facts. ;)
>
>
As I said in my prior message: it's been considered, and discarded rather
quickly. It doesn't need much further introspection than that. A couple of
major points:

* Brian W's point is correct: there's not much migration cost at all moving
to PHP7. Moving between PHP versions has always been pretty easy for us in
MW--we write very conservative code as it is.
* Various (there's lots from lots of people) benchmarks routinely show HHVM
and PHP7--especially 7.1+--performance to be roughly on par, depending on
workloads. We can get some firmer numbers here.
** A bunch of major projects have already dropped HHVM for PHP7+. Etsy,
Symphony, Wordpress (they no longer test against it)
* Swapping to HHVM/Hack would abandon many/most of our downstream users --
the stats Stas pointed to way far back shows world install base as well
under 0.5% of all PHP runtimes.
* Speaking of downstream users: HHVM has always been a second-class citizen
on non-Linux OSes. It's always been wonky on OSX (I would know, I was the
first person to ever get it built), and I don't think anyone's ever got it
working on Windows outside of Cygwin--please correct me if I'm wrong?
* It greatly complicates setup and development work for both WMF and
volunteers.
** Did I mention almost nobody has up to date packages for this?
*  PHP has a long-documented history of working as a proper FLOSS project.
Facebook's track record here has been less than stellar--it comes in fits
and starts and there's a lot of "throwing code over the wall"
** We have a core PHP contributor (Stas) on this list. Other than
occasional patches we've shipped upstream to HHVM, I doubt anyone would
claim themselves a core HHVM contributor around here [maybe Tim early on,
heh]
* Choices HHVM is going to make upstream (references, destuctors) are a
/huge/ issue for us. The former is basically a requirement for our Hooks
system and the latter is used all over the dang place for profiling and
other fun scope-based tricks.
* Libraries we use -- composer, phpunit, etc can not be depended on to
support Hack in the long term, and there's no tooling in the HHVM world for
this (promises notwithstanding).

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] HHVM vs. Zend divergence

[Chad]

On Tue, Sep 19, 2017 at 10:28 AM C. Scott Ananian <canan...@wikimedia.org>
wrote:

> On Tue, Sep 19, 2017 at 1:17 PM, Chad <innocentkil...@gmail.com> wrote:
>
> > be clear: we never chose HHVM for Hack. We don't use Hack. The one
> > experiment I had at trying Hack never panned out. MediaWiki is in PHP,
> not
> > Hack.
> >
>
> To be super clear: MediaWiki is in *PHP5*.  The choices are:
>
> 1) MediaWiki will always be in PHP5.
> 2) MediaWiki will eventually migrate to PHP7, or
> 3) MediaWiki will eventually migrate to Hack.
>
> Is anyone arguing for #1?
>
> So we've got two backwards-incompatible choices to make, eventually.
>

I see everyone saying #1 for now and #2 down the road. You're the only one
here who seems to think #3 is even worth considering. The rest of us
have--rightly--dismissed it already.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] HHVM vs. Zend divergence

[Chad]

On Tue, Sep 19, 2017 at 9:40 AM C. Scott Ananian <canan...@wikimedia.org>
wrote:

> Fair enough.  My point is just that we should stop and reflect that this is
> a major inflection point.  Language choices are sticky, so this decision
> will have significant long-term implications.  We should at least stop to
> evaluate PHP7 vs Hack and determine which is a better fit for our codebase,
> and do due diligence on both sides (count how many engineers, how many open
> source contributors, commit rates, etc).  HHVM has been flirting with a
> LLVM backend, and LLVM itself has quite a large and active community.  The
> PHP community has had issues with proper handling of security patches in
> the past.  I'm suggesting to proceed cautiously and have a proper
> discussion of all the factors involved instead of over-simplifying this to
> "community" vs "facebook".
>
>
I'm not trying to simplify this into community vs. facebook. And let's also
be clear: we never chose HHVM for Hack. We don't use Hack. The one
experiment I had at trying Hack never panned out. MediaWiki is in PHP, not
Hack.

The *only* reason we're having a language discussion is because HHVM has
announced that they're abandoning PHP in favor of Hack. If someone had some
to the list last week and said "Hey let's abandon PHP for XYZLang" they
would've been rightly laughed off.

The debate here is between runtimes for PHP, and on the long enough
timescale there's only one option. PHP has a long-standing history of being
a viable runtime. HHVM does not.

I don't see this as an A/B choice at all, but rather a clear path forward.
So sure: let's have an RfC/TechComm meeting to work out the details, but
let's not pretend that option #2 is even remotely viable. It is not.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] HHVM vs. Zend divergence

[Chad]

On Mon, Sep 18, 2017 at 5:44 PM Stas Malyshev <smalys...@wikimedia.org>
wrote:

> Hi!
>
> > * Rather than "drifting away" from PHP, their top priority plans
> > include removing core language features like references and destructors.
>
> Wow. I can see why they're doing it (those are sources of most
> complications ans security issues in the language, references being
> especially weird and tricky). But dropping those would certainly mean
> very heavy incompatibility with PHP, by which point it'd be completely
> separate language. Which probably excludes Max's #2 from consideration
> altogether.
>
> > Actually, I think a year is a pretty short time for ops to switch to
> > PHP 7. I think we need to decide on this pretty much immediately.
>
> Should it be on the TechCom agenda and should we have some public
> discussion on IRC in RFC format for this soon?
>
>
I see zero reason for us to go through all the formalities, unless we want
to really. I have yet to see anyone (on list, or on IRC anywhere at all
today) where anyone suggested (2) was a good idea at all. It's a
horrifically bad idea. I don't consider it remotely viable and would do
everything possible to veto such a move.

(1) is impossible as a long-term goal.

So this basically means we're going the route of (3) which is the only way
we can actually expect people to use MediaWiki outside of Wikimedia. And
considering we never really implemented any HHVM/Hack specific features (as
far as I know) it means there's no reason we have to continue to support
HHVM at all once WMF has moved off of it.

It's been a fun experiment for the past couple of years, but it's time to
move on.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can we drop revision hashes (rev_sha1)?

[Chad]

We could keep it in the XML dumps (it's part of the XSD after all)...just
compute it at export time. Not terribly hard, I don't think, we should have
the parsed content already on hand

-Chad

On Fri, Sep 15, 2017 at 12:51 PM James Hare <jamesmh...@gmail.com> wrote:

> What I wonder is – does this *need* to be a part of the database table, or
> can it be a dataset generated from each revision and then published
> separately? This way each user wouldn’t have to individually compute the
> hashes while we also get the (ostensible) benefit of getting them out of
> the table.
>
> On September 15, 2017 at 12:41:03 PM, Andrew Otto (o...@wikimedia.org)
> wrote:
>
> We should hear from Joseph, Dan, Marcel, and Aaron H on this I think, but
> from the little I know:
>
> Most analytical computations (for things like reverts, as you say) don’t
> have easy access to content, so computing SHAs on the fly is pretty hard.
> MediaWiki history reconstruction relies on the SHA to figure out what
> revisions revert other revisions, as there is no reliable way to know if
> something is a revert other than by comparing SHAs.
>
> See
>
> https://wikitech.wikimedia.org/wiki/Analytics/Data_Lake/Edits/Mediawiki_history
> (particularly the *revert* fields).
>
>
>
> On Fri, Sep 15, 2017 at 1:49 PM, Erik Zachte <ezac...@wikimedia.org>
> wrote:
>
> > Compute the hashes on the fly for the offline analysis doesn’t work for
> > Wikistats 1.0, as it only parses the stub dumps, without article content,
> > just metadata.
> > Parsing the full archive dumps is a quite expensive, time-wise.
> >
> > This may change with Wikistats 2.0 with has a totally different process
> > flow. That I can't tell.
> >
> > Erik Zachte
> >
> > -Original Message-
> > From: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] On
> > Behalf Of Daniel Kinzler
> > Sent: Friday, September 15, 2017 12:52
> > To: Wikimedia developers <wikitech-l@lists.wikimedia.org>
> > Subject: [Wikitech-l] Can we drop revision hashes (rev_sha1)?
> >
> > Hi all!
> >
> > I'm working on the database schema for Multi-Content-Revisions (MCR) <
> > https://www.mediawiki.org/wiki/Multi-Content_Revisions/Database_Schema>
> > and I'd like to get rid of the rev_sha1 field:
> >
> > Maintaining revision hashes (the rev_sha1 field) is expensive, and
> becomes
> > more expensive with MCR. With multiple content objects per revision, we
> > need to track the hash for each slot, and then re-calculate the sha1 for
> > each revision.
> >
> > That's expensive especially in terms of bytes-per-database-row, which
> > impacts query performance.
> >
> > So, what do we need the rev_sha1 field for? As far as I know, nothing in
> > core uses it, and I'm not aware of any extension using it either. It
> seems
> > to be used primarily in offline analysis for detecting (manual) reverts
> by
> > looking for revisions with the same hash.
> >
> > Is that reason enough for dragging all the hashes around the database
> with
> > every revision update? Or can we just compute the hashes on the fly for
> the
> > offline analysis? Computing hashes is slow since the content needs to be
> > loaded first, but it would only have to be done for pairs of revisions of
> > the same page with the same size, which should be a pretty good
> > optimization.
> >
> > Also, I believe Roan is currently looking for a better mechanism for
> > tracking all kinds of reverts directly.
> >
> > So, can we drop rev_sha1?
> >
> > --
> > Daniel Kinzler
> > Principal Platform Engineer
> >
> > Wikimedia Deutschland
> > Gesellschaft zur Förderung Freien Wissens e.V.
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Recommending Firefox to users using legacy browsers?

[Chad]

On Wed, Sep 6, 2017 at 2:31 AM Antoine Musso <hashar+...@free.fr> wrote:

> On 05/09/2017 17:47, Chad wrote:
> > On Tue, Sep 5, 2017 at 2:28 AM Joaquin Oltra Hernandez <
> > jhernan...@wikimedia.org> wrote:
> >
> >> I think that people using old browsers on desktop, are most surely
> doing it
> >> because they have to (company policy on locked down computers) and
> showing
> >> them a banner or similar is only going to detract from their experience
> >> with information they don't neither want nor need.
> >>
> >>
> > To be honest, bugging these users means hopefully they'll bug their IT
> > managers to finally get their fucking asses in the 2010s and stop being
> > irresponsible. I won't lose any sleep over annoying them...
>
> That is not how it works in a big company. To deploy a new browser you
> gotta:
> * update the base images used to deploy the workstations
> * revalidate all the applications
> * revalidate all the web apps with that new browser (cough ActiveX,
> Java, Flash, obsolete js etc)
> * roll it incrementally to the ten or hundred of thousands of workstation
>
> That is a 12-18 months project and you don't do it "just" to upgrade a
> browser that is however working fine for your business applications.
>
> In the end the IT managers cant do it as easily as they would want due
> to time/cost.  I got your point for sure, and I am pretty sure web
> compatibility has forced them to update their browser already, they are
> just lagging by a few years.
>
>
I'm well aware of how corporate IT works. A 12-18 month projectthat
should've been started in May 2010 when Microsoft announced the end of XP
support. That's like 80+ months and counting. I'm sorry, but if you're the
IT executive who thinks that is acceptable then you should resign in
absolute shame and leave the field IT.

I never said it was cheap, or easy, but that it has to be done. Maybe if we
annoy the CEO of a company a directive will magically come down from on
high ;-)


>
> I am pretty sure the popup would be annoying to a lot of users.
> Hopefully when most websites no more work in their browser, they would
> eventually switch to a new computer. But that can take a decade+ to
> achieve :-(
>
>
The internet is quickly disappearing from these browsers. Warning them
beforehand is better than just one day going dark with no explanation.


> If we crafted nice tutorials as to how to install and use the few
> browsers we offer, that might help.  Chrome and Firefox most probably
> already have such tutorials for all the OSes they support.
>
>
Link to their sites. They typically have nice big INSTALL ME buttons on
their homepages :)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Recommending Firefox to users using legacy browsers?

[Chad]

On Tue, Sep 5, 2017 at 2:28 AM Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> I think that people using old browsers on desktop, are most surely doing it
> because they have to (company policy on locked down computers) and showing
> them a banner or similar is only going to detract from their experience
> with information they don't neither want nor need.
>
>
To be honest, bugging these users means hopefully they'll bug their IT
managers to finally get their fucking asses in the 2010s and stop being
irresponsible. I won't lose any sleep over annoying them...

However, there's two other groups who would be annoyed/confused by such
banners:

* Parents/grandparents who got their Windows XP laptop 12 years ago and
don't know how to upgrade--nor do they care, as long as they can check
their e-mail and print pictures :)
* People in lower-income locales for whom upgrading is a cost-prohibitive
endeavor

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Recommending Firefox to users using legacy browsers?

[Chad]

On Fri, Sep 1, 2017 at 3:57 PM Neil Patel Quinn <nqu...@wikimedia.org>
wrote:

> I understand the desire to avoid playing favorites by directing users to a
> list of browsers rather than a single one, but I think that cuts against
> *both
> *the goals of doing this in the first place.
>
> The first goal is to nudge users to upgrade from an insecure, less-capable
> browser to a modern one. But if we present them a list of 10 alternatives
> (or even 2), they're far more likely to get stuck in choice paralysis [1]
> and far less likely to actually do what we want and upgrade.
>
>
Indeed. A big list of "HEY PICK ONE OF THESE" means we'll end up fracturing
our users over a bunch of browsers that most of us would never even use
ourselves. I merely suggested Chromium alongside Firefox because it's also
free/open, even if driven by the BIG EVIL GOOGLE.


> The second goal is to strengthen non-profit, open-web-focused browser
> makers by increasing their market share. As I see it, the best way to do
> this is to nudge all our users towards a single, high-quality browser which
> already has significant market share, rather than distributing them across
> many different browsers with tiny market shares.
>
>
Indeed, like I said above. However high quality is subjective...my
experiences with Firefox have been horrible the last several years, which
is why I stick to Chromium/Chrome mostly. That's why I'd suggest like
basically 2-3 options tops so we don't play favorites :)


> I'd suggest that the best areas for debate are (1) whether these are good
> goals, (2) whether their benefits justify interrupting users' browsing, and
> (3) which single browser would be the best destination
>
> Obviously, my answers are (1) yes, (2) yes, and (3) Firefox, but some will
> disagree :)
>
>
(1) Eh, maybe. I care mostly because these older platforms are horribly
insecure and if we can get people on a half-decent browser on those
platforms then that's a win (cf: T118181 and all its various linked tasks).
Javascript is way down the list of why I care here :)

(2) We already interrupt some of these users anyway per the TLS migration
stuff I mentioned in (1) above. I think the rollout there--start with small
percentages and slowly ramp up prior to there being a deadline is a good
route to go.

(3) I would *really* like to have 2--maybe 3--browsers to list. There's
zero reason to make users think there's only one option when there's a
couple of valid ones.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Recommending Firefox to users using legacy browsers?

[Chad]

On Fri, Sep 1, 2017 at 6:55 AM Federico Leva (Nemo) <nemow...@gmail.com>
wrote:

> At least until a proper resource exists, just directing people to the
> latest Firefox is probably the most reasonable option (we certainly
> can't support the incumbent).
>
>
Is linking to Firefox and Chromium an option?

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki 1.28 is now LTS?

[Chad]

I thought Module:Version handled this template automatically. Sorry about
that folks!

-Chad

On Fri, Jul 14, 2017 at 6:46 AM Andre Klapper <aklap...@wikimedia.org>
wrote:

> On Fri, 2017-07-14 at 13:17 +, Robert Vogel wrote:
> > according to [1] the MediaWiki 1.28.2 was a LTS release. On [2] I can
> > not find a hint about this. Is that maybe a mistake?
>
> Thanks! Tgr fixed this in
>
> https://www.mediawiki.org/w/index.php?title=Template%3ADownloadMediaWiki=revision=2513208=2478759
>
> andre
> --
> Andre Klapper | Wikimedia Bugwrangler
> http://blogs.gnome.org/aklapper/
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [MediaWiki-announce] MediaWiki 1.29 Available!

[Chad Horohoe]

Hello everyone,

I am happy to announce the availability the general release of MediaWiki
1.29!

MediaWiki 1.29 includes all changes released in the smaller 1.29.0-wmf.*
software deployments to Wikimedia sites over six months, totaling
approximately 1640 commits by around 140 authors. This is a large release
that contains many new features and bug fixes.

This is a summary of the major changes of interest to users and
administrators:
* https://www.mediawiki.org/wiki/MediaWiki_1.29

You can always consult the RELEASE-NOTES-1.29 file for the full list of
changes in this version.

Full release notes:
*
https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_29/RELEASE-NOTES-1.29
* https://www.mediawiki.org/wiki/Release_notes/1.29

**
Download:
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-1.29.0.tar.gz
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-core-1.29.0.tar.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-1.29.0.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-core-1.29.0.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

-Chad
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [MediaWiki-announce] MediaWiki 1.29.0-rc.1 now available

[Chad Horohoe]

Hi all,

First, I'd like apologize for the extreme delay in getting 1.29 out the
door. There's been a bunch of rather nasty bugs that have popped right
around the first release candidate. They've mostly been related to database
transactions and job queue support. As both are kind of crucial I've
decided to hold back the release. As of today, all pending blockers to 1.29
have been resolved. But considering the severity, I'd like to get one last
release candidate in. So without further ado

I'd like to announce the immediate availability of MediaWiki 1.29.0-rc.1,
the second release candidate for 1.29.x. Links at the end of the e-mail.

This is not a final release and should not be used for production websites.
As always please do try out the release candidate in a test environment.
It's how we find bugs that didn't surface in initial development :)

Full release notes:
https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_29/RELEASE-NOTES-1.29
https://www.mediawiki.org/wiki/Release_notes/1.29

**
Download:
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-1.29.0-rc.1.tar.gz

Core only (no extensions):
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-core-1.29.0-rc.1.tar.gz.sig

Patch to previous version (1.29.0-rc.0):
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-1.29.0-rc.1.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-1.29.0-rc.1.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-core-1.29.0-rc.1.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-1.29.0-rc.1.patch.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

--
Chad Horohoe
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Ops] Change to version number incrementing for weekly Wikimedia MediaWiki deploys

[Chad Horohoe]

I think a branch that's never deployed is likely to confuse people more,
SWAT
immediately comes to mind (which branches do I port to?)

And while it's fixable, it would mean a non-checked-out branch wouldn't get
automatically cleaned up during our weekly pruning.

All in all: I like this move. It makes "how old is a branch" math much
easier.

-Chad

On Tue, Jul 11, 2017 at 1:31 PM Mukunda Modell <mmod...@wikimedia.org>
wrote:

> Maybe we could prevent breaking things by always creating a branch for
> every wmf.XX number. That is, always create a new branch, even on weeks
> with no official branch cut. So in the case of wmf.8, we would simply
> branch off from wmf.7, thus extending wmf.7 for another week but under a
> new name, instead of creating a new branch from master.
>
> On Tue, Jul 11, 2017 at 3:20 PM, Greg Grossmeier <g...@wikimedia.org>
> wrote:
>
>> Hello all,
>>
>> I failed to send this notice out before when the change was made; mea
>> culpa.
>>
>> Background:
>> * We start a new 1.XX-wmf.XX series after each MW 'tarball' release. For
>>   example right now we're in the 1.30-wmf.XX series now that 1.29 is
>>   nearing release.
>>
>> The change:
>> * Instead of only incrementing the wmf.XX portion when a new branch is
>>   actually deployed to Wikimedia production servers, we will increment
>>   that number each week regardless.
>> ** For example, last week we did not push a new branch out to production
>>due to the short work week. That week would have been 1.30-wmf.8. We
>>thus skipped wmf.8 and are now on wmf.9 this week.
>>
>> Why?
>> We hope to make the creation of the weekly deployment branch
>> (1.XX-wmf.XX) automatic in the near future. This will allow us to put
>> that on a cron and not worry about special cases (another special case
>> being when we hold back the train due to a bad regression). This (every
>> week gets a wmf.XX number) should simplify logic in many places.
>>
>> Thanks!
>>
>> Greg on behalf of the Release Engineering team
>>
>>
>> PS: Yeah, we could have just gone with ISO week numbers, but we didn't
>> want to change too much in the version string to reduce the chance of
>> breaking too many other tools.
>> PPS: And yes, my failure to pre-announce this instead of post-announce
>> caused at least the ReleaseTaggerBot to break this week. Mea cupla.
>>
>> --
>> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
>> | Release Team ManagerA18D 1138 8E47 FAC8 1C7D |
>>
>> ___
>> Ops mailing list
>> o...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/ops
>>
>>
> ___
> Ops mailing list
> o...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/ops
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tidy will be replaced by RemexHTML on Wikimedia wikis latest by June 2018

[Chad]

On Thu, Jul 6, 2017 at 5:02 AM Subramanya Sastry <ssas...@wikimedia.org>
wrote:

> 6. Tools to assist editors: Linter & ParserMigration
> 
> In October 2016, at the parsing team offsite, Kunal ([[User:Legoktm
> (WMF)]])
> dusted off the stalled wikitext linting project [11] and (with the help
> from
> a bunch of people on the Parsoid, db/security/code review areas) built the
> Linter extension that surfaces wikitext errors that Parsoid knows about to
> let editors fix them.
>
> Earlier this year, we decided to use Linter in service of Tidy replacement.
> Based on our earlier testing results, we have added a set of high-priority
> linter categories that identifies specific wikitext markup patterns on wiki
> pages that need to be fixed [12].
>
>
Linter is certainly awesome and kudos to Kunal for getting that done and
pushed out. [[Special:LintErrors]] is super useful, I'm wondering if there's
a dashboard somewhere that summarizes this across all wikis? If so, I
missed it. If not, it should be pretty easy to wire something up to grab
info
from api.php on all wikis.

I think it'd help for coordinating cross-wiki efforts (bots, tools) as well
as
seeing which wikis are "done" and could be early candidates for migration.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] "How can MW 1.27.1 be stable with a broken hook?"

[Chad]

On Tue, Jun 27, 2017 at 2:10 PM Stephan Gambke <s7ep...@protonmail.com>
wrote:

>
>
>
>
>  Original Message 
> Subject: Re: [Wikitech-l] "How can MW 1.27.1 be stable with a broken hook?"
> Local Time: June 27, 2017 10:41 PM
> UTC Time: June 27, 2017 8:41 PM
> From: innocentkil...@gmail.com
> To: Stephan Gambke <s7ep...@protonmail.com>, Wikimedia developers <
> wikitech-l@lists.wikimedia.org>
>
> On Tue, Jun 27, 2017 at 1:02 PM Stephan Gambke <s7ep...@protonmail.com>
> wrote:
>
>> See https://phabricator.wikimedia.org/T118683
>> https://gerrit.wikimedia.org/r/#/c/244044 introduced a change that
>> causes warnings on extensions that implemented the TitleMoveComplete hook
>> signature according to documentation at
>> https://www.mediawiki.org/wiki/Manual:Hooks/TitleMoveComplete.
>> https://gerrit.wikimedia.org/r/#/c/249189/ tried to fix it but did not.
>>
>> Since then several MW versions have been released without a fix. All that
>> happened was that the hook description on mw.org got a warning banner.
>> Any comments? Any suggestions as to a way forward?
>> As 244044 is clearly breaking stuff, what about completely reverting it?
>>
>
> Sometimes hook signatures change. A new LTS is a perfectly ok release to
> put them
> in--LTS just means we won't be introducing breaking changes between
> releases of
> that series and we're committed to back porting security fixes for some
> time.
>
> This was released with 1.27.0 from the beginning -- it was not later
> backported as an
> incompatible 1.27.1+ fix.
>
> Extensions that are affected should be updated for 1.27.0+ support --
> that's the fix...nothing
> from core.
>
> -Chad
>
>
> So deprecation policies do not apply in this case? Why not?
>

If deprecation policies were broken, that's not really the LTS cycle that
caused it. The two policies don't really reference one another.

Ideally we can figure out a better way here.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] "How can MW 1.27.1 be stable with a broken hook?"

[Chad]

On Tue, Jun 27, 2017 at 1:02 PM Stephan Gambke <s7ep...@protonmail.com>
wrote:

> See https://phabricator.wikimedia.org/T118683
> https://gerrit.wikimedia.org/r/#/c/244044 introduced a change that causes
> warnings on extensions that implemented the TitleMoveComplete hook
> signature according to documentation at
> https://www.mediawiki.org/wiki/Manual:Hooks/TitleMoveComplete.
> https://gerrit.wikimedia.org/r/#/c/249189/ tried to fix it but did not.
>
> Since then several MW versions have been released without a fix. All that
> happened was that the hook description on mw.org got a warning banner.
> Any comments? Any suggestions as to a way forward?
> As 244044 is clearly breaking stuff, what about completely reverting it?
>
>
Sometimes hook signatures change. A new LTS is a perfectly ok release to
put them
in--LTS just means we won't be introducing breaking changes between
releases of
that series and we're committed to back porting security fixes for some
time.

This was released with 1.27.0 from the beginning -- it was not later
backported as an
incompatible 1.27.1+ fix.

Extensions that are affected should be updated for 1.27.0+ support --
that's the fix...nothing
from core.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [MediaWiki-announce] 1.29.0-rc.0 released, timeline on 1.29.0, EOL of 1.23.x

[Chad Horohoe]

Hi,

I'd like to announce the immediate availability of MediaWiki 1.29.0-rc.0,
the first release candidate for 1.29.x. Links at the end of the e-mail.

This is not a final release and should not be used for production websites.
Notably, there's a few major outstanding bugs related to the job queue. As
always please do try out the release candidate in a test environment. It's
how we find bugs that didn't surface in initial development :)

The timeline for 1.29.0 is a little fuzzy right now, and I apologize. The
outstanding bugs have been pretty hard to isolate and fix, but I see
progress so I hope those working on them will have it all resolved soon.

Finally, per the version lifecycle I'm announcing the End Of Life of
MediaWiki 1.23.x. The final release in this series was 1.23.17. Those
installations using the versions as LTS should upgrade to 1.27.3, as 1.27.x
is the supported LTS branch through June 2019.

Full release notes:
https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_29/RELEASE-NOTES-1.29
https://www.mediawiki.org/wiki/Release_notes/1.29


**
Download:
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-1.29.0-rc.0.tar.gz

Core only, no extensions:
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-core-1.29.0-rc.0.tar.gz.sig

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-core-1.29.0-rc.0.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.29/mediawiki-1.29.0-rc.0.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

--
Chad Horohoe
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [MediaWiki-announce] Security release 1.27.3 and 1.28.2

[Chad Horohoe]

Hello!

I would like to announce the immediate availability of security releases
1.27.3
and 1.28.2. Due to a mistake in packaging, the releases 1.27.2 and 1.28.1
did
not contain the fix for SyntaxHighlight_GeSHi. This new release does contain
that fix.

The task in question: https://phabricator.wikimedia.org/T158689

If you are not running this extension, you do not necessarily need to
upgrade.

Thanks, and I apologize for any confusion in the matter.

Full release notes:
https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_27/RELEASE-NOTES-1.27
https://www.mediawiki.org/wiki/Release_notes/1.27

https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_28/RELEASE-NOTES-1.28
https://www.mediawiki.org/wiki/Release_notes/1.28

**
1.27.3
**
Download:
https://releases.wikimedia.org/mediawiki/1.27/mediawiki-1.27.3.tar.gz

Core only, no extensions:
https://releases.wikimedia.org/mediawiki/1.27/mediawiki-core-1.27.3.tar.gz.sig

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.27/mediawiki-1.27.3.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.27/mediawiki-core-1.27.3.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

**
1.28.2
**
Download:
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.2.tar.gz

Core only, no extensions:
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-core-1.28.2.tar.gz.sig

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.2.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-core-1.28.2.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 1.29 branched, master is now 1.30

[Chad]

Hi,

What it says in the subject :) I've made the REL1_29 branch from master (as
of 273eea7357c546d1a1aafd73320e10e8ddac79eb) and have bumped the version to
1.29.0-rc.0 (from alpha). All extensions, skins and vendor have been
branched as well.

I've just landed the change to master that bumps it to 1.30.0-rc.0.

Let the backports begin! (I want to be generous this time too, so bring 'em
at me)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] REL1_29 approaching, pencils down

[Chad]

Hi,

We're coming up on the month of May, which means we'll be working on a 1.29
release! As
the initial step, I'd like to create a branch for REL1_29 this week barring
any major objections.
I'm thinking Thursday evening after we've finished this week's train.

Then we'll be in the normal patch master + backport process we all know and
love until we
do the release (looking at May 25th).

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] "must be of type int, int given"

[Chad]

On Mon, Apr 17, 2017 at 2:07 PM Gergo Tisza <gti...@wikimedia.org> wrote:

> On Mon, Apr 17, 2017 at 8:35 PM, Denny Vrandečić <vrande...@gmail.com>
> wrote:
>
> > Value returned from function f() must be of type int, int given
>
>
> Have you enabled PHP7 mode
> <https://docs.hhvm.com/hhvm/configuration/INI-settings#php-7-settings>?
>
>
I'm curious if we should enable this in Vagrant and our Jenkins testing so
we can avoid weird failures that spawned this thread.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] "must be of type int, int given"

[Chad]

On Mon, Apr 17, 2017 at 3:07 PM Denny Vrandečić <vrande...@gmail.com> wrote:

> Ah, that's a good point! Sorry, stupid error.
>
> I think I did it now - adding to
> mediawiki-vagrant/puppet/hieradata/common.yaml (I hope that is the right
> approach).
>
> Now I get the following error, which seems unrelated to my extension. Hm.
>
> Apr 17 21:48:57 mediawiki-vagrant hhvm[29575]: #033[0m#033[22;31m[Mon Apr
> 17 21:48:57 2017] [hphp] [29575:7ff81f7ff700:1:02] [] Exception handler
> threw an object exception: TypeError: Argument 5 passed to pfsockopen()
> must be an instance of float, int given in
> /vagrant/mediawiki/includes/libs/redis/RedisConnectionPool.php:233
>
>
That almost sounds like we should be casting the input to
RedisConnectionPool
to a float from an int. If it expects floats, easy enough to provide
one...could just
check with ctype_digit() so we can handle ints and strings that look like
numbers.

And probably throw an exception if we're not, it's probably bogus config or
a bug
if we're looking at non-numeric input.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [MediaWiki-announce] 1.23.17 bugfix release

[Chad Horohoe]

Hello!

I would like to announce the release of MediaWiki 1.23.17. There was an
issue
in the 1.23.16 release that prevented it from running on PHP 5.3
installations.
Considering the report wasn't very widespread, I'm guessing most people
haven't
been affected yet. If you are, this release will fix it.

Apologies for any issues you may have encountered during your upgrade. The
updated links can be found below:

Full release notes for 1.23.17:


**
1.23.17
**

Download:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.17.tar.gz

Download without bundled extensions:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.17.tar.gz

Patch to previous version (1.23.16)::
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.17.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.17.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.17.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.17.patch.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [MediaWiki-announce] Security Release: 1.28.1 / 1.27.2 / 1.23.16

[Chad]

Yes, the tags will be following very shortly. It takes a long time for a
large
pile of changes to make its way through CI.

Apologies for any confusion!

-Chad

On Thu, Apr 6, 2017 at 3:38 PM James Montalvo <jamesmontal...@gmail.com>
wrote:

> This is great. Thank you. I don't believe tags were created for 1.27 or
> 1.28, though.
>
> On Apr 6, 2017 4:40 PM, "Chad Horohoe" <choro...@wikimedia.org> wrote:
>
> > Hello!
> >
> > I would like to announce the release of MediaWiki 1.28.1, 1.27.2 and
> > 1.23.16!
> >
> > These releases fix five security issues in core and one for the extension
> > SyntaxHighlight_GeSHi. Download links are given at the end of this email.
> >
> > Please note that next month is the End-Of-Life date for MediaWiki 1.23.
> > This
> > means that MediaWiki 1.23.16 will be the last security release for that
> > version, barring any unforeseen issues. We would strongly encourage users
> > of
> > MediaWiki 1.23 to upgrade to MediaWiki 1.27, released in June 2016, or a
> > yet
> > newer version as soon as possible. MediaWiki 1.27 will be supported until
> > June
> > 2019. See <https://www.mediawiki.org/wiki/Version_lifecycle> for more
> > information.
> >
> > This release also serves as a maintenance release for these branches.
> >
> > == Security fixes ==
> > * (T109140) (T122209) Special:UserLogin and Special:Search allow redirect
> >   to interwiki links. (CVE-2017-0363, CVE-2017-0364)
> > * (T144845) XSS in SearchHighlighter::highlightText() when
> >   $wgAdvancedSearchHighlighting is true.  (CVE-2017-0365)
> > * (T125177) API parameters may now be marked as "sensitive" to keep
> >   their values out of the logs.  (CVE-2017-0361)
> > * (T150044) "Mark all pages visited" on the watchlist now requires a CSRF
> >   token.  (CVE-2017-0362)
> > * (T156184) Escape content model/format url parameter in message.
> >   (CVE-2017-0368)
> > * (T151735) SVG filter evasion using default attribute values in DTD
> >   declaration. (CVE-2017-0366)
> > * (T48143) Spam blacklist ineffective on encoded URLs inside file
> inclusion
> >   syntax's link parameter. (CVE-2017-0370)
> > * (T108138) Sysops can undelete pages, although the page is protected
> > against
> >   it. (CVE-2017-0369)
> >
> > The following only affects 1.27 and above and is not included in the 1.23
> > upgrade:
> > * (T161453) LocalisationCache will no longer use the temporary directory
> >   in its fallback chain when trying to work out where to write the cache.
> >   (CVE-2017-0367)
> >
> > The following fix is for the SyntaxHighlight extension:
> > * (T158689) Parameters injection in SyntaxHighlight results in multiple
> > vulnerabilities.
> >   (CVE-2017-0372)
> >
> > == Links to all mentioned tasks ==
> > https://phabricator.wikimedia.org/T109140
> > https://phabricator.wikimedia.org/T122209
> > https://phabricator.wikimedia.org/T144845
> > https://phabricator.wikimedia.org/T125177
> > https://phabricator.wikimedia.org/T150044
> > https://phabricator.wikimedia.org/T156184
> > https://phabricator.wikimedia.org/T151735
> > https://phabricator.wikimedia.org/T161453
> > https://phabricator.wikimedia.org/T48143
> > https://phabricator.wikimedia.org/T108138
> > https://phabricator.wikimedia.org/T158689
> >
> > == Release notes ==
> >
> > Full release notes for 1.28.1:
> > <https://www.mediawiki.org/wiki/Release_notes/1.28>
> >
> > Full release notes for 1.27.2:
> > <https://www.mediawiki.org/wiki/Release_notes/1.27>
> >
> > Full release notes for 1.23.16:
> > <https://www.mediawiki.org/wiki/Release_notes/1.23>
> >
> > For information about how to upgrade, see
> > <https://www.mediawiki.org/wiki/Manual:Upgrading>
> >
> > **
> > 1.23.16
> > **
> > Download:
> > https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.16.tar.gz
> >
> > Download without bundled extensions:
> > https://releases.wikimedia.org/mediawiki/1.23/mediawiki-
> > core-1.23.16.tar.gz
> >
> > Patch to previous version (1.23.15), without interface text:
> > https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.16.patch.gz
> >
> > Interface text changes:
> > https://releases.wikimedia.org/mediawiki/1.23/mediawiki-
> > i18n-1.23.16.patch.gz
> >
> > GPG signa

[Wikitech-l] [MediaWiki-announce] Security Release: 1.28.1 / 1.27.2 / 1.23.16

[Chad Horohoe]

Hello!

I would like to announce the release of MediaWiki 1.28.1, 1.27.2 and
1.23.16!

These releases fix five security issues in core and one for the extension
SyntaxHighlight_GeSHi. Download links are given at the end of this email.

Please note that next month is the End-Of-Life date for MediaWiki 1.23. This
means that MediaWiki 1.23.16 will be the last security release for that
version, barring any unforeseen issues. We would strongly encourage users of
MediaWiki 1.23 to upgrade to MediaWiki 1.27, released in June 2016, or a yet
newer version as soon as possible. MediaWiki 1.27 will be supported until
June
2019. See  for more
information.

This release also serves as a maintenance release for these branches.

== Security fixes ==
* (T109140) (T122209) Special:UserLogin and Special:Search allow redirect
  to interwiki links. (CVE-2017-0363, CVE-2017-0364)
* (T144845) XSS in SearchHighlighter::highlightText() when
  $wgAdvancedSearchHighlighting is true.  (CVE-2017-0365)
* (T125177) API parameters may now be marked as "sensitive" to keep
  their values out of the logs.  (CVE-2017-0361)
* (T150044) "Mark all pages visited" on the watchlist now requires a CSRF
  token.  (CVE-2017-0362)
* (T156184) Escape content model/format url parameter in message.
  (CVE-2017-0368)
* (T151735) SVG filter evasion using default attribute values in DTD
  declaration. (CVE-2017-0366)
* (T48143) Spam blacklist ineffective on encoded URLs inside file inclusion
  syntax's link parameter. (CVE-2017-0370)
* (T108138) Sysops can undelete pages, although the page is protected
against
  it. (CVE-2017-0369)

The following only affects 1.27 and above and is not included in the 1.23
upgrade:
* (T161453) LocalisationCache will no longer use the temporary directory
  in its fallback chain when trying to work out where to write the cache.
  (CVE-2017-0367)

The following fix is for the SyntaxHighlight extension:
* (T158689) Parameters injection in SyntaxHighlight results in multiple
vulnerabilities.
  (CVE-2017-0372)

== Links to all mentioned tasks ==
https://phabricator.wikimedia.org/T109140
https://phabricator.wikimedia.org/T122209
https://phabricator.wikimedia.org/T144845
https://phabricator.wikimedia.org/T125177
https://phabricator.wikimedia.org/T150044
https://phabricator.wikimedia.org/T156184
https://phabricator.wikimedia.org/T151735
https://phabricator.wikimedia.org/T161453
https://phabricator.wikimedia.org/T48143
https://phabricator.wikimedia.org/T108138
https://phabricator.wikimedia.org/T158689

== Release notes ==

Full release notes for 1.28.1:


Full release notes for 1.27.2:


Full release notes for 1.23.16:


For information about how to upgrade, see


**
1.23.16
**
Download:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.16.tar.gz

Download without bundled extensions:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.16.tar.gz

Patch to previous version (1.23.15), without interface text:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.16.patch.gz

Interface text changes:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-i18n-1.23.16.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.16.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.16.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.16.patch.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-i18n-1.23.16.patch.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

**
1.27.2
**
Download:
https://releases.wikimedia.org/mediawiki/1.27/mediawiki-1.27.2.tar.gz

Download without bundled extensions:
https://releases.wikimedia.org/mediawiki/1.27/mediawiki-core-1.27.2.tar.gz

Patch to previous version (1.27.1), without interface text:
https://releases.wikimedia.org/mediawiki/1.27/mediawiki-1.27.2.patch.gz

Interface text changes:
https://releases.wikimedia.org/mediawiki/1.27/mediawiki-i18n-1.27.2.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.27/mediawiki-core-1.27.2.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.27/mediawiki-1.27.2.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.27/mediawiki-1.27.2.patch.gz.sig
https://releases.wikimedia.org/mediawiki/1.27/mediawiki-i18n-1.27.2.patch.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

**
1.28.1

[Wikitech-l] [MediaWiki-announce] Security pre-release announcement: 1.28.1 / 1.27.2 / 1.23.16

[Chad Horohoe]

Hi,

Tomorrow, April 6th we will be performing a security release of MediaWiki
for all supported branches. The new versions will be 1.28.1, 1.27.2 and
1.23.16. This will resolve 9 issues in MediaWiki core, and one in a bundled
extension.

Have a great day,

--
Chad Horohoe & Sam Reed
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] AMD petition

[Chad]

Brian is correct, this is off-topic. Let's please not continue this thread
here.

-Chad

On Mon, Mar 13, 2017 at 3:44 PM bawolff <bawolff...@gmail.com> wrote:

> With all due respect, and as much as I support things like this, this
> is offtopic for wikitech-l.
>
> --
> Brian
>
> On Mon, Mar 13, 2017 at 10:03 PM, James Salsman <jsals...@gmail.com>
> wrote:
> > Please join me in asking AMD to open-source the PSP (backdoor) in
> > their chips -- a chance to regain secure x86 hardware.
> >
> >
> https://www.change.org/p/advanced-micro-devices-amd-release-the-source-code-for-the-secure-processor-psp
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ArchCom Monutes, News, and Outlook

[Chad]

On Mon, Mar 13, 2017 at 6:37 AM MZMcBride <z...@mzmcbride.com> wrote:

> bawolff wrote:
> >+1 to this being inconvenient. I don't always attend arch com
> >meetings, but usually do if I happen to be online during the time. If
> >its a hangout, it is extremely unlikely I would attend unless I was
> >specifically proposing an RFC.
>
> Proprietary and capped at 25 participants? No thank you.
>
>
Piling on. I hate hangouts for small meetings with like 5 people, much
less a large group. They're *awful*

The 25 participant problem should make the whole idea a non-starter for
this.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] SHA-1 hash officially broken

[Chad]

On Fri, Feb 24, 2017 at 10:57 AM Brion Vibber <bvib...@wikimedia.org> wrote:

> Added a tracking/epic task on phab:
> https://phabricator.wikimedia.org/T158986
>
> Attach any specific things to that as subtasks, y'all.
>
>
Thanks for getting the discussion started. I was talking about this
yesterday
with some people and yeah, file and revision sha1s immediately came to
mind.

Also possibly a future issue: Git--but we'll mostly want to wait for various
upstreams to make progress here. There's some interesting thoughts over
at this fork[0] (h/t to Tim)

But, like you said (and Dan pointed out on the task), this is far from a
drop
everything situation...we just need to start making some inroads to this
sooner rather than later. Since it's broken, making it faster is an
optimization
problem so the writing is on the wall.

-Chad

[0]
https://github.com/peff/git/commit/b55aa200a0b3af58dc9e0accadc719bb47573ac3
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] MediaWiki-Vagrant needs testers for Debian Jessie changes

[Chad Horohoe]

On Tue, Feb 14, 2017 at 6:53 PM Bryan Davis <bd...@wikimedia.org> wrote:

> Give things a try and report issues as children of the tracking task
> for this migration
>

Works for me!

Using OSX 10.12.3 using VirtualBox 5.1.14 and Vagrant 1.8.5

Would test with my Parallels install, but it's out of commission at the
moment.

Major kudos on wrapping this up, been wanting this for awhile.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Account creation on Phabricator currently restricted

[Chad]

On Mon, Jan 30, 2017 at 7:16 PM Chad <innocentkil...@gmail.com> wrote:

> Hi,
>
> Due to a current vandalism/spam threat, I've enabled administrator approval
> of all new accounts. Hopefully this won't have to stay enabled long.
>
> Will update when it's turned back off.
>
>
Forgot to mention, this was turned back off earlier today. Thanks for your
patience!

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Account creation on Phabricator currently restricted

[Chad]

Hi,

Due to a current vandalism/spam threat, I've enabled administrator approval
of all new accounts. Hopefully this won't have to stay enabled long.

Will update when it's turned back off.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ResistanceManual.org looking for co-maintainers

[Chad]

Nope.

mediawiki-l would be more appropriate, as the support list.

-Chad

On Mon, Jan 30, 2017 at 1:27 PM Steven Walling <steven.wall...@gmail.com>
wrote:

> Dear Brad,
>
> Yes.
>
> On Mon, Jan 30, 2017 at 6:42 AM Brad Jorsch (Anomie) <
> bjor...@wikimedia.org>
> wrote:
>
> > On Sun, Jan 29, 2017 at 6:38 PM, Ori Livneh <ori.liv...@gmail.com>
> wrote:
> >
> > > Resistance Manual <
> > https://www.resistancemanual.org/Resistance_Manual_Home
> > > >
> > > is a guide for organizing resistance to the policies of the Trump
> > > administration in the United States. The site is running MediaWiki
> 1.28,
> > > and its admins are looking for help maintaining the site. The main page
> > > says to reach out to i...@staywoke.org if interested.
> > >
> >
> > Is "some random wiki needs sysadmins" really on-topic for this list?
> >
> >
> > --
> > Brad Jorsch (Anomie)
> > Senior Software Engineer
> > Wikimedia Foundation
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Deprecation logging in production

[Chad]

On Thu, Jan 26, 2017 at 10:19 AM Daniel Kinzler <daniel.kinz...@wikimedia.de>
wrote:

> * Extensions and skins bundled with the MediaWiki tarball MUST NOT trigger
> hard
> deprecation warnings and MUST be updated to use the new code.
>
>
> But that's just for bundeled extensions, not deployed extensions. There is
> this:
>
>
> * As one of the principles of MediaWiki, developers should ensure any
> removals
> will not cause issues in the Wikimedia setup and extensions deployed
> there. If
> they do, developers should expect to be reverted by Wikimedia system
> administrators.
>
>
As the person to changed the tarball criteria to MUST NOT, I would
be totally in favor of extending that to deployed extensions.

Removing code that's still used in production is embarrassing/sad
and offenders should be ashamed ;-)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] +2 request for yurik in mediawiki and maps-dev

[Chad]

If he had them before, he should retain them. I've granted both.

-Chad

On Tue, Jan 24, 2017 at 7:45 PM Legoktm <legoktm.wikipe...@gmail.com> wrote:

> Hi,
>
> After speaking with Yurik, I've filed
> <https://phabricator.wikimedia.org/T156219> on his behalf to restore his
> membership in the mediawiki and maps-dev groups.
>
> I would appreciate guidance in whether these rights can be summarily
> granted since he used to have them, or if it needs to go through the
> full process.
>
> -- Legoktm
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [SECURITY] CentralAuth - Tokens & apioutput.js

[Chad]

Hi,

This shouldn't affect very many installations as CentralAuth is very
WMF-specific but letting everyone know that a fix for CentralAuth has just
been released.

It allowed user impersonation by a combination of the apioutput.js (used
for api.php output customization) and the central auth cookie.

The bug is: https://phabricator.wikimedia.org/T144573
The gerrit change is: https://gerrit.wikimedia.org/r/#/c/16/

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [SECURITY] Math extension - shell invocation followup

[Chad]

Hi all,

In the process of the previous security release, T124940 was fixed in
core MediaWiki (it deals with unacceptably long shell inputs). There was
also a related fix in Math that I just noticed had never been released--even
thought it was disclosed (with a patch) on the task in question.

It's been published to https://gerrit.wikimedia.org/r/#/c/09/ (for
master)
and is being backported to all supported branches (1.28.x, 1.27.x, 1.23.x)

This isn't an extension we bundle in core MW which explains the oversight.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] PHP fatal error: Call to undefined method stdClass::get()

[Chad]

Already done:

https://wikitech.wikimedia.org/wiki/Incident_documentation/20170111-multiversion

-Chad

On Thu, Jan 12, 2017 at 8:27 AM Chad <innocentkil...@gmail.com> wrote:

> Yeah, I need to write one up, I'll try to get it done today or tomorrow.
>
> There won't be much to learn / do as a result, but it needs to be
> documented at the very least.
>
> -Chad
>
>
> On Thu, Jan 12, 2017 at 8:18 AM Pine W <wiki.p...@gmail.com> wrote:
>
> Understood. Thanks for your efforts and the quick rollback. These things
> happen sometimes, despite best efforts. When you have time to write an
> incident report, I'd like to read it in the hope that I might learn
> something from it, and perhaps others will as well.
>
> Pine
>
>
> On Thu, Jan 12, 2017 at 8:06 AM, Chad <innocentkil...@gmail.com> wrote:
>
> > So this was my fault. I've been working on an ongoing effort to clean up
> > our multiversion code in wmf-config (this is the piece that allows us to
> > run
> > different versions on different wikis).
> >
> > Despite rigorous testing in beta & on the production debug servers, the
> > patch failed. I rolled back within seconds.
> >
> > This code is proving rather difficult to clean up :(
> >
> > -Chad
> >
> > On Thu, Jan 12, 2017 at 6:54 AM Pine W <wiki.p...@gmail.com> wrote:
> >
> > > Thanks Florian. I'm curious to know what happened. When you have a
> > > minute, perhaps
> > > you could point me to the phab ticket or incident report.
> > >
> > > Pine
> > >
> > >
> > > On Wed, Jan 11, 2017 at 11:44 AM, Florian Schmidt <
> > > florian.schmidt.wel...@t-online.de> wrote:
> > >
> > > > It's already fixed, thanks for reporting!
> > > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] Im
> > > > Auftrag von Pine W
> > > > Gesendet: Mittwoch, 11. Januar 2017 20:37
> > > > An: wikitech-l@lists.wikimedia.org
> > > > Betreff: [Wikitech-l] PHP fatal error: Call to undefined method
> > > > stdClass::get()
> > > >
> > > > I just started getting a lot of these errors when trying to load
> pages
> > on
> > > > multiple Wikimedia sites.
> > > >
> > > > Pine
> > > > ___
> > > > Wikitech-l mailing list
> > > > Wikitech-l@lists.wikimedia.org
> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > >
> > > >
> > > > ___
> > > > Wikitech-l mailing list
> > > > Wikitech-l@lists.wikimedia.org
> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] PHP fatal error: Call to undefined method stdClass::get()

[Chad]

Yeah, I need to write one up, I'll try to get it done today or tomorrow.

There won't be much to learn / do as a result, but it needs to be
documented at the very least.

-Chad

On Thu, Jan 12, 2017 at 8:18 AM Pine W <wiki.p...@gmail.com> wrote:

> Understood. Thanks for your efforts and the quick rollback. These things
> happen sometimes, despite best efforts. When you have time to write an
> incident report, I'd like to read it in the hope that I might learn
> something from it, and perhaps others will as well.
>
> Pine
>
>
> On Thu, Jan 12, 2017 at 8:06 AM, Chad <innocentkil...@gmail.com> wrote:
>
> > So this was my fault. I've been working on an ongoing effort to clean up
> > our multiversion code in wmf-config (this is the piece that allows us to
> > run
> > different versions on different wikis).
> >
> > Despite rigorous testing in beta & on the production debug servers, the
> > patch failed. I rolled back within seconds.
> >
> > This code is proving rather difficult to clean up :(
> >
> > -Chad
> >
> > On Thu, Jan 12, 2017 at 6:54 AM Pine W <wiki.p...@gmail.com> wrote:
> >
> > > Thanks Florian. I'm curious to know what happened. When you have a
> > > minute, perhaps
> > > you could point me to the phab ticket or incident report.
> > >
> > > Pine
> > >
> > >
> > > On Wed, Jan 11, 2017 at 11:44 AM, Florian Schmidt <
> > > florian.schmidt.wel...@t-online.de> wrote:
> > >
> > > > It's already fixed, thanks for reporting!
> > > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] Im
> > > > Auftrag von Pine W
> > > > Gesendet: Mittwoch, 11. Januar 2017 20:37
> > > > An: wikitech-l@lists.wikimedia.org
> > > > Betreff: [Wikitech-l] PHP fatal error: Call to undefined method
> > > > stdClass::get()
> > > >
> > > > I just started getting a lot of these errors when trying to load
> pages
> > on
> > > > multiple Wikimedia sites.
> > > >
> > > > Pine
> > > > ___
> > > > Wikitech-l mailing list
> > > > Wikitech-l@lists.wikimedia.org
> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > >
> > > >
> > > > ___
> > > > Wikitech-l mailing list
> > > > Wikitech-l@lists.wikimedia.org
> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] PHP fatal error: Call to undefined method stdClass::get()

[Chad]

So this was my fault. I've been working on an ongoing effort to clean up
our multiversion code in wmf-config (this is the piece that allows us to run
different versions on different wikis).

Despite rigorous testing in beta & on the production debug servers, the
patch failed. I rolled back within seconds.

This code is proving rather difficult to clean up :(

-Chad

On Thu, Jan 12, 2017 at 6:54 AM Pine W <wiki.p...@gmail.com> wrote:

> Thanks Florian. I'm curious to know what happened. When you have a
> minute, perhaps
> you could point me to the phab ticket or incident report.
>
> Pine
>
>
> On Wed, Jan 11, 2017 at 11:44 AM, Florian Schmidt <
> florian.schmidt.wel...@t-online.de> wrote:
>
> > It's already fixed, thanks for reporting!
> >
> > -Ursprüngliche Nachricht-
> > Von: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] Im
> > Auftrag von Pine W
> > Gesendet: Mittwoch, 11. Januar 2017 20:37
> > An: wikitech-l@lists.wikimedia.org
> > Betreff: [Wikitech-l] PHP fatal error: Call to undefined method
> > stdClass::get()
> >
> > I just started getting a lot of these errors when trying to load pages on
> > multiple Wikimedia sites.
> >
> > Pine
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Gerrit downtime tomorrow evening / early morning

[Chad Horohoe]

Hi,

Doing a (minor) point release upgrade to Gerrit tomorrow evening to deal
with a data loss bug we can potentially hit.
While we're offline, we're going to push out a change that enables logging
to Logstash.

Window is 17:00-19:00 SF time (that's 01:00-03:00 UTC).

Thanks for your patience :)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Offering internationalized programming facilities within WM enviroment

[Chad]

On Thu, Dec 22, 2016 at 10:42 AM mathieu stumpf guntz <
psychosl...@culture-libre.org> wrote:

> * mediawiki.util get renamed to mediawiki.outil : there is no problem
> with that, isn't it?
> * then changed to alors : there is no problem with that, isn't it?
>
>
Yes, that is a problem. As pointed out by others: it makes grepping for
code when doing refactoring basically impossible as I'd have to know
a list of every possible translation of "util." That's not a good use of
developer time at all.

I mean these ideas have merit on the face of them, but I'm totally in the
"this is nice but probably not worth the maintenance burden" camp along
with Gergo.

T150417 was declined, and for good reasons I think.

I think ideas like Babylscript are more useful for a project where you've
got a lot of developers in a *single* non-English language. For example,
a team of Italians who would rather work in Italian than English. In our
case, we've got *many* languages and being able to use things across
wikis/languages is important.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Gerrit: login issues for some (hopefully only a few)

[Chad Horohoe]

Hi,

We upgraded to Gerrit 2.13.3 today from 2.12.2. However, a couple of users
have reported being unable to login. Based on reports and investigation, I'm
thinking/hoping this is only affecting 11 users.

However, if you find yourself unable to login with the message "Cannot
assign
username  to account ; name already in use," please
do chime in on Phab[0].

Thanks and have a good evening,

[0] https://phabricator.wikimedia.org/T152640
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Deployments: upcoming holidays and their impact

[Chad]

On Wed, Dec 7, 2016 at 9:22 AM Alex Monk <am...@wikimedia.org> wrote:

> Are we also going to be disabling l10nupdate then? That's surely more risky
> than syncing beta's files (which aren't even loaded by production apaches)
>
>
Sounds like a plan!

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Deployments: upcoming holidays and their impact

[Chad]

On Wed, Dec 7, 2016 at 12:52 AM Legoktm <legoktm.wikipe...@gmail.com> wrote:

> On 12/06/2016 03:32 PM, Greg Grossmeier wrote:
> > Reminder: This next week (Dec 12th) is the last normal week before the
> > end of year holiday season deploy freeze goes into effect. Plan
> > accordingly.
>
> Does the freeze also affect the beta cluster? Or just production?
>
>
Considering it's best practice to fully sync config changes to production,
even if they're no-ops intended for beta I would say yes

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit upgrade (w/ short downtime) tomorrow

[Chad]

On Tue, Dec 6, 2016 at 10:23 AM Florian Schmidt <
florian.schmidt.wel...@t-online.de> wrote:

> Just for information (and half as a question, so if this is correct,
> simply ignore this comment :P): The phabricator task is:
> https://phabricator.wikimedia.org/T146350 ?
>
>
That is correct :)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Gerrit upgrade (w/ short downtime) tomorrow

[Chad Horohoe]

Hi all,

Tomorrow evening (18:30–19:30 UTC) I'll be taking Gerrit offline shortly
for a planned upgrade from 2.12.5 to 2.13.3. It shouldn't take the full
hour, but you never know :)

If you play the deployment game regularly, you'll notice I've cancelled[0]
tomorrow's "SF Morning SWAT" window because it overlaps with the time I
picked ;-)

Thanks!

-Chad

[0]
https://wikitech.wikimedia.org/w/index.php?title=Deployments=revision=1088543=1085547
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [MediaWiki-announce] MediaWiki 1.28 now available!

[Chad Horohoe]

On Mon, Nov 28, 2016 at 12:08 PM Chad Horohoe <choro...@wikimedia.org>
wrote:

> Hello everyone,
>
> I am happy to announce the availability the general release of MediaWiki
> 1.28!
>
>
Hi!

One minor note. The RELEASE-NOTES-1.28 was not updated prior to release and
still mentions that the software is an alpha/beta and not suitable for
production use.

It certainly is, and I apologize for the oversight. This is fixed in the
REL1_28 release branch and will be included in a 1.28.1, if/when it's
announced (I didn't figure a whole release bump was necessary for a
documentation fix).

Sorry if this caused any confusion!

-Chad
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [MediaWiki-announce] MediaWiki 1.28 now available!

[Chad Horohoe]

Hello everyone,

I am happy to announce the availability the general release of MediaWiki
1.28!

MediaWiki 1.28 includes all changes released in the smaller 1.28.0-wmf.*
software deployments to Wikimedia sites over six months, totaling
approximately 2100 commits by around 120 authors. This is a large release
that contains many new features and bug fixes.

This is a summary of the major changes of interest to users and
administrators:
* https://www.mediawiki.org/wiki/MediaWiki_1.28

You can always consult the RELEASE-NOTES-1.28 file for the full list of
changes in this version.

Full release notes:
*
https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_28/RELEASE-NOTES-1.28
* https://www.mediawiki.org/wiki/Release_notes/1.28

**
Download:
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.0.tar.gz
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-core-1.28.0.tar.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.0.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-core-1.28.0.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

-Chad
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] WikipediaP2P

[Chad]

On Tue, Nov 22, 2016 at 11:33 AM bawolff <bawolff...@gmail.com> wrote:

> See also related discussion last year
> https://lists.wikimedia.org/pipermail/wikitech-l/2015-November/084143.html
>
>
And the year before, and before that, and before that... it's a perennial
proposal ;-)


> Personally I think this whole thing is a bad idea
> * Its questionable how much this would actually save anything. Cached
> anon hits are pretty cheap
>

Indeed.


> * This basically doesn't do cach invalidation. Lets just have
> vandalism stay around for long periods of time
>

Yep, that's always been a problem in these proposals.

* Probably makes it much easier for third parties to determine what
> you are browsing. (Censorship resistant p2p networks is still an open
> research problem last I checked)
>

Plus this.


> * Probably makes it easier for adversaries to selectively censor
> specific articles
> [I haven't looked at the implementation, but I'm going to guess here]
>

Basically because of the above.


> * Questionable how it would verify content is legit. What's stopping a
> malicious actor from putting random malicious js into the p2p network,
> or someone replacing articles with biased versions.
>
>
Same thing here. That being saidI'm curious if there's some sort of
middle ground here. I wonder how much (c|w)ould be saved by serving
static assets (CSS, UI images, etc etc) via P2P. Prolly not much in the
US/Europe, but in places with poor latency this could be interesting.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [MediaWiki-announce] 1.26 EOL announcement

[Chad Horohoe]

Hi,

With the release of MediaWiki 1.28, the lifetime of MediaWiki version
1.26.x has come to an end.

Users still using MediaWiki 1.26.x are advised to upgrade to version
1.28.0, the latest stable version.

-Chad
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Gerrit issue (mostly with mediawiki/core)

[Chad]

Hi all,

Gerrit decided to crap itself this morning while doing garbage collection
on the repositories. As a result, you may have some issues when fetching
the latest objects from the repo. Right now MediaWiki core seems to be the
only repo noticeably affected, but I'm currently checking into the status
for all repositories.

Fresh clones are not affected. If you end up hitting a problem in fetching,
the following workaround should get you back in shape:

  cp .git/config .git/config.backup
  git remote remove origin
  mv .git/config.backup .git/config
  git fetch

Investigation is ongoing. If you hit any other repos than MW that seem to
be having issues, please chime in on
https://phabricator.wikimedia.org/T151676

Have a good weekend!

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [MediaWiki-announce] Second release candidate for 1.28 (1.28.0-rc.1)

[Chad Horohoe]

Hiya!

I am happy to announce the availability of the second release candidate of
the new MediaWiki 1.28 series!

Sorry for the delay, it should've been out last week. Other things got in
the
way. There's not been a lot of churn on 1.28-related stuff, so I still
anticipate
doing the final release next week. That means, barring any blockers, there
won't be an RC2.

Full release notes:
*
https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_28/RELEASE-NOTES-1.28
* https://www.mediawiki.org/wiki/Release_notes/1.28

Known issues and final release blockers can be found in Phabricator:
https://phabricator.wikimedia.org/project/board/1982/

-- Chad

**
Download:
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.0-rc.1.tar.gz
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-core-1.28.0-rc.1.tar.gz
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.0-rc.1.patch.gz
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-i18n-1.28.0-rc.1.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.0-rc.1.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-core-1.28.0-rc.1.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.0-rc.1.patch.gz.sig
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-i18n-1.28.0-rc.1.patch.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Update on WMF account compromises

[Chad]

On Thu, Nov 17, 2016 at 12:18 AM Antoine Musso <hashar+...@free.fr> wrote:

> Le 16/11/2016 à 19:19, Pine W a écrit :
> >
> > (0) Consider testing your password strength with a tool like
> > http://www.testyourpassword.com/; be sure that the tool you use does not
> > send your chosen password over the Internet and instead tests it locally.
>
> By using an online testing tool, you are effectively breaking the very
> first rule:
>
>  DO NOT GIVE OUT YOUR PASSWORD.  EVER.
>
> Using that site is exactly like sharing your password with a random
> stranger in the world.  Even if you trusted that website, and audited
> the code at a given point in time, you have no guarantee the site hasn't
> changed or that it is not collecting passwords.
>
>
Not to mention, it's plain-old-insecure HTTP, so of course anyone and
their mother's uncle could be sniffing the traffic ;-)

Same rule goes for a "generate a random password" site. Don't use
them.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Announcement] Search improvements for file properties

[Chad]

On Mon, Nov 14, 2016 at 11:46 AM Chris Koerner <ckoer...@wikimedia.org>
wrote:

> Hello,
>
> You can now search for file properties such as file size and and file type
> on Commons. This includes file media type, MIME type, size, width, height,
> resolution, and bit depth.
>
>
This. Is. Awesome.  I've been wanting to see something like this for ages.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 1.28 branching release dates and such :)

[Chad]

Hi!

S, it's that wonderful time of year where we start prepping for a new
general release
of MediaWiki! This one will be 1.28.0, and it'll be based on all of the
1.28 wmf branches we've
been doing over the past 6 months.

Step 1 is cutting the branch, which I plan to do tomorrow from the same
branch point which we
cut the 1.28.0-wmf.23. This is slightly different, in that we won't be
cutting from master a few days
after the WMF branch, and takes some of the pressure off of creating
1.29.0-wmf.1 the following
week.

So here's the timeline:
Tomorrow (Oct 25) - Cut REL1_28 from wmf.23, master goes to 1.29-alpha
Tues (Nov 1) - First deployment of 1.29 to WMF [wmf.1, obviously]
Wednesday (Nov 2) - Do rc.0 [giving us a few days for any backports that
came up in wmf.23 rollout]
Following two Wednesdays (Nov 9, 16) - Do rc.1 and rc.2
Wednesday (Nov 23) - Final release of MW

I'll be updating MW.org shortly.

Tyler Cipriani's assisting me with this release, so expect to see some RCs
with his name
(and signatures) on them :)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Setting up a new Tomcat servlet in production?

[Chad]

On Mon, Oct 17, 2016 at 5:14 AM Adam Wight <awi...@wikimedia.org> wrote:

> The challenges are first that it's based on a Tomcat backend
> <
> https://github.com/Wikimedia-TW/han3_ji7_tsoo1_kian3_WM/blob/master/src/idsrend/services/IDSrendServlet.java
> >,
> which I'm not sure is precedented in our current ecosystem, and second that
> the code uses Chinese variable and function names, which should
> unfortunately be Anglicized by convention, AIUI.  Finally, there might be
> security issues around the rendered text itself, if it were misused to mask
> content.
>
> I'm mostly asking this list for help with the question of using Tomcat in
> production.
>
>
So we don't use Tomcat anywhere right now, so yeah that's unprecedented.
I did attempt it awhile back for Gerrit (like, years ago), but I found
Tomcat
to be a huge pain in the butt for basically no gain (in that case).

It's not impossible--there's packages and all that fun stuff for Tomcat and
related tooling--but I think that Tomcat generally isn't worth the overhead
and maintenance burden for a single service.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit was down today

[Chad Horohoe]

Heya!

Gonna reboot Gerrit real quick this morning. Turns out "cobalt" did not
have hyperthreading turned on. Services should be back momentarily!

-Chad

On Fri, Oct 7, 2016 at 2:07 PM Daniel Zahn <dz...@wikimedia.org> wrote:

> The Gerrit migration is over. It is back up and served from new server
> "cobalt" now. It feels faster than before as well.  Thanks much to
> Brandon Black for help.
>
> ___
> Engineering mailing list
> engineer...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Gerrit was down today

[Chad Horohoe]

Hi!

Sorry for the extended downtime! From what we can tell, it appears as though
the machine that Gerrit is running on (lead) is having some hardware issues
that
are making the CPU misbehave. We've worked around it for now, so things
should
be up (and Zuul is processing CI events just fine).

However, since it appears it's a hardware problem, we're planning to
migrate off
of lead to a new machine (cobalt). The public IP addresses will not be
changing.
The plan right now is to do this migration tomorrow with a scheduled
downtime
at 17:00UTC (10:00 PST).

We'll be keeping a close eye on things in the meantime, so if things
deteriorate
again we can start the migration sooner.

(and yeah, wikitech incident report to follow, I'm a little burnt out right
now though)

Thanks again for bearing with us!

-Chad

On Thu, Oct 6, 2016 at 2:32 PM Greg Grossmeier <g...@wikimedia.org> wrote:

> (It wasn't just you)
>
> Gerrit was down today starting around 17:49 UTC. It is now back up and
> services are coming back online.
>
> A full investigation into the cause of the outage is still on-going.[0]
>
> Apologies for the downtime.
>
> WMF Release Engineering
>
> [0] https://etherpad.wikimedia.org/p/gerrit-outage-20161006
> But this is missing a lot of the information/discussion that is
> happening in #wikimedia-operations on Freenode. A link to the
> incident report will be pasted into that etherpad when it is
> created.
>
> --
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | Release Team ManagerA18D 1138 8E47 FAC8 1C7D |
>
> ___
> Engineering mailing list
> engineer...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 2016W40 ArchCom-RFC meeting: future of magic links

[Chad]

On Tue, Oct 4, 2016 at 11:52 PM Legoktm <legoktm.wikipe...@gmail.com> wrote:

> > 2.  Deprecation strategy for Wikimedia wikis (e.g. Wikipedia)
>
> Most of the migration can be done using a bot with some basic regexes,
> but the key part will be adapting templates to generate links (e.g. ISBN
> citation templates) instead of relying upon magic link functionality.
>
>
Question: do we have any kinds of numbers yet on how widely these are
used across WMF projects?

It's info something we could probably get out of either Elasticsearch or the
dumps probably :)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Opening up MediaWiki dev summit in January?

[Chad]

On Wed, Sep 14, 2016 at 4:01 PM MZMcBride <z...@mzmcbride.com> wrote:

> >>* how can we improve the quality of our software, and pay down the
> >> technical debt we've accumulated over the years?
> >
> >Pro: again, a favorite topic of talk-over-beers among developers.  One
> >could imagine a whole summit devoted to going through our software stack
> >component by component, identifying the cruft hidden in each, and making
> >concrete plans to banish it.
> >Con: this opinion might be controversial, but my impression is that we're
> >actually pretty good at low-level refactoring.  There are plenty of things
> >we are hesitant to change (say, wikitext syntax!), but I don't get the
> >feeling that the barrier is in engineering.  The problem is mostly a
> >management one: how can engineering communicate the time spend and value
> >added by "invisible" maintenance and refactoring; how can we get
> >management to allocate more dedicates resources to this?  I don't think
> >there's much technical debate about what to work on, if we had the
> >resources to do so.
>
> I think this problem exists in most companies/organizations. Nobody wants
> to pay down technical debt; building new features is a lot more exciting.
>

Bummer. I think paying down tech debt is fun and way more rewarding
than making shiny new things.

But I'm also weird as hell...


>
> >Ok, so what have we learned from this?  Even if others have different
> >opinions about each of Rob's proposed topics, which are the *sort* of
> >things we'd like the dev summit to be about?  Radical ideas?  Stuff
> >developers bitch over beers about?  Vague umbrella topics ("make wiki
> >easier to use") that we can crowd a bunch of stuff under?  Something else
> >entirely?
>
> In my experience, the greatest value derived from these types of events
> (summits, hackathons, unconferences, whatever other cutesy word) is having
> unstructured time to explore and think and poke and discuss with people
> about pet projects and other neat ideas. The structured and more formal
> sessions, with their broad themes for whatever year it is, are usually
> boring and ill-fitting.
>
>
This. I usually find myself skipping most sessions. One of two things
happen:

1) You sit there and listen to someone else talk to you, or
2) It's ostensibly a group discussion, but the group is too big and nothing
useful gets discussed because you spend too much time listening to 30
different voices.

(1) bores me to tears. (2) is basically useless.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] Fwd: [Translators-l] Purodha passed away

[Chad]

Another idea could be doing the tasks he had assigned to him.

https://phabricator.wikimedia.org/maniphest/?statuses=open()=PHID-USER-pkzunphfdvlecngun3iz#R

-Chad

On Sat, Sep 3, 2016 at 10:15 AM Luke <luke081...@web.de> wrote:

> Would be a nice idea, John. Sadly there isn't a way yet, to make a query
> for tokens (At least I didn't find one).
>
> For people who want to leave a last message to him, we got a condolence
> list at dewiki:
> https://de.wikipedia.org/wiki/Benutzer:Purodha/Kondolenzliste
>
> --
> Luke
>
> Am 03.09.2016 um 02:21 schrieb jay...@gmail.com:
> > On Sat, 3 Sep 2016 02:43 Amir E. Aharoni, <amir.ahar...@mail.huji.ac.il>
> > wrote:
> >> This is very sad.
> >>
> >> He was not only a prolific translator, but a prolific bug reporter, too.
> >>
> >> May he rest in peace.
> > Indeed. Also developed patches.
> >
> > His activity can be seen here:
> >
> > https://phabricator.wikimedia.org/p/Purodha/
> >
> > Can we find the open bugs he voted for/awarded tokens to?
> > And do the hardest one in his honour?
> >
> > --
> > John
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> >
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] git release branches

[Chad]

On Mon, Aug 29, 2016 at 8:34 AM John <phoenixoverr...@gmail.com> wrote:

> my thought would not only be for the bundled extensions but for
> *everything*
> under skins/ and extensions/ to get a given REL branch when a release is
> set. It might mean that some extensions get a REL for a non-compatible
> branch but it would cover those extensions where devs forget to cut
> branches.
>
>
Devs don't have to remember to cut branches, I cut a REL1_* for all
extensions & skins during the release cycle. They aren't retroactively
done for new extensions or skins sure, but they should all be there.

I was talking more about putting the "bundled" ones (ie: those in the
tarballs) as submodules of core release branches like we do for the
wmf/* branches.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] git release branches

[Chad]

On Mon, Aug 29, 2016 at 8:04 AM John <phoenixoverr...@gmail.com> wrote:

> Can we get a repo for each major release that contains core, skins, and all
> extensions in a single checkout? Right now I am updating and with all of
> the sub modules, I am running into issues where I cant set a branch on the
> extensions/ repo for REL 1_27 and get all extensions as of that branching,
> Instead I am forced to go thru one by one and manually set it, if and only
> if a given extension has said branch set, otherwise I am out of luck.
>
> Getting everything together would cause a larger checkout, but keeps things
> together for those who want to pick and choose.
>
>
It's on my todo list to add all the extensions and skins that are bundled
in a release to the core release branch as submodules, just haven't gotten
around to it yet.

In addition to the problems/benefits you point out, it also means that the
extensions and skins would be included in the signed tags for each
release, aiding in reproducibility of a release.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [MediaWiki-announce] Security Release - 1.27.1, 1.26.4, 1.23.15

[Chad Horohoe]

I would like to announce the release of MediaWiki 1.27.1, 1.26.4, 1.23.15!

These releases fix five security issues in core and one for the extension
PdfHandler. Download links are given at the end of this email.

== Security fixes ==

* (T139565) API: Generate head items in the context of the given title
(CVE-2016-6335)
* (T137264) XSS in unclosed internal links (CVE-2016-6334)
* (T133147) Escape '<' and ']]>' in inline