Re: [Wikitech-l] Patchsets by new Gerrit contributors waiting for code review and/or merge

[Paladox]

 I wonder if we could create a polygerrit plugin and just display a daily or 
weekly list of changes for users to review.
On Friday, 29 June 2018, 01:36:50 BST, Jean-Rene Branaa 
 wrote:  
 
 Hola,

I like this, thanks for doing it.  As part of the Stewardship push,
I've yet to start measuring/baselining responsiveness, this will help
bring attention to reviews that are languishing.  I also like the fact
that you're specifying the stewards (or lack there of). Again, helpful
for me too :-)

Cheers,

JR

On Thu, Jun 28, 2018 at 2:59 AM Andre Klapper  wrote:
>
> (Resurrecting the weekly posts from late 2016. Feedback welcome.)
>
>
> CR0: Please review and provide guidance if you are familiar with the
> code, and decide (CR±1 or CR±2):
>
> * https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/431320/
> ** Trim whitespaces from the end of the text
> ** 2018-May-06
> ** Maintainers/Stewards: Contributors > Parsing team
>
> * https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/164049/
> ** Add Tatar LanguageConverter
> ** 2018-May-24
> ** Maintainers/Stewards: Contributors > Parsing team
>
> * 
> https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/ApprovedRevs/+/434052/
> ** Add support for custom content types other than WikitextContent
> ** 2018-Jun-17
> ** Maintainers/Stewards: ?
>
> * https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/PageForms/+/441021/
> ** edit-with-form-tab-not-displaying
> ** 2018-Jun-19
> ** Maintainers/Stewards: ?
>
>
> CR+1: Please help make a decision (CR±1, CR±2) on these CR+1 patches:
>
> * 
> https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/ExternalData/+/421525/
> ** Cast the variable to an array to prevent PHP warnings
> ** 2018-March-23
> ** Maintainers/Stewards: ?
>
>
> Read https://www.mediawiki.org/wiki/Gerrit/Code_review#By_project how
> you can get notified of new patches in your code areas of interest.
>
> Thanks in advance for your reviews!
>
>
> Maintainers/Stewards data taken from 
> https://www.mediawiki.org/wiki/Developers/Maintainers
> CR0 source: 
> https://gerrit.wikimedia.org/r/#/q/ownerin:newcomers+status:open+label:Verified%253D1+label:Code-Review%253D0
> CR+1 source: 
> https://gerrit.wikimedia.org/r/#/q/ownerin:newcomers+status:open+label:Verified%253E%253D1+label:Code-Review%253E%253D%252B1+-label:Code-Review%253C%253D0
>
> --
> Andre Klapper | Bugwrangler / Developer Advocate
> https://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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Patchsets by new Gerrit contributors waiting for code review and/or merge

[Jean-Rene Branaa]

Hola,

I like this, thanks for doing it.  As part of the Stewardship push,
I've yet to start measuring/baselining responsiveness, this will help
bring attention to reviews that are languishing.  I also like the fact
that you're specifying the stewards (or lack there of). Again, helpful
for me too :-)

Cheers,

JR

On Thu, Jun 28, 2018 at 2:59 AM Andre Klapper  wrote:
>
> (Resurrecting the weekly posts from late 2016. Feedback welcome.)
>
>
> CR0: Please review and provide guidance if you are familiar with the
> code, and decide (CR±1 or CR±2):
>
> * https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/431320/
> ** Trim whitespaces from the end of the text
> ** 2018-May-06
> ** Maintainers/Stewards: Contributors > Parsing team
>
> * https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/164049/
> ** Add Tatar LanguageConverter
> ** 2018-May-24
> ** Maintainers/Stewards: Contributors > Parsing team
>
> * 
> https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/ApprovedRevs/+/434052/
> ** Add support for custom content types other than WikitextContent
> ** 2018-Jun-17
> ** Maintainers/Stewards: ?
>
> * https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/PageForms/+/441021/
> ** edit-with-form-tab-not-displaying
> ** 2018-Jun-19
> ** Maintainers/Stewards: ?
>
>
> CR+1: Please help make a decision (CR±1, CR±2) on these CR+1 patches:
>
> * 
> https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/ExternalData/+/421525/
> ** Cast the variable to an array to prevent PHP warnings
> ** 2018-March-23
> ** Maintainers/Stewards: ?
>
>
> Read https://www.mediawiki.org/wiki/Gerrit/Code_review#By_project how
> you can get notified of new patches in your code areas of interest.
>
> Thanks in advance for your reviews!
>
>
> Maintainers/Stewards data taken from 
> https://www.mediawiki.org/wiki/Developers/Maintainers
> CR0 source: 
> https://gerrit.wikimedia.org/r/#/q/ownerin:newcomers+status:open+label:Verified%253D1+label:Code-Review%253D0
> CR+1 source: 
> https://gerrit.wikimedia.org/r/#/q/ownerin:newcomers+status:open+label:Verified%253E%253D1+label:Code-Review%253E%253D%252B1+-label:Code-Review%253C%253D0
>
> --
> Andre Klapper | Bugwrangler / Developer Advocate
> https://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

Re: [Wikitech-l] CI jobs using npm might suffer from a 10 minutes delay

[Antoine Musso]

On 28/06/2018 16:25, Antoine Musso wrote:
> Hello,
> 
> Since June 27th, any CI job running 'npm install' might suffer from a 10
> minutes extra delay.
> 
> Somehow when requesting package informations from the NpmJS CDN
> (CloudFlare), the connection holds for ten minutes.  npm just idles
> waiting for a reply. Then eventually it shows:
> 
>   npm ERR! registry error parsing json

> Our task: https://phabricator.wikimedia.org/T198348

Npmjs seems to have implemented a fix although we are still hitting the
issue:  https://status.npmjs.org/incidents/51c7q80zsj9f


A few minutes ago, I have bumped the default timeout from 30 minutes to
45 minutes.  So jobs will still be slow, but at least they should
succeed (when they should).

https://gerrit.wikimedia.org/r/#/c/integration/config/+/442988/


-- 
Antoine Musso


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

Re: [Wikitech-l] [Multimedia] Video output changing to WebM VP9/Opus soon

[Pine W]

Thanks for the update. As you can imagine, I am very interested in this!

Pine
( https://meta.wikimedia.org/wiki/User:Pine )

 Original message From: Brion Vibber  
Date: 6/28/18  1:54 PM  (GMT-08:00) To: Wikimedia Foundation Multimedia Team 
 Cc: Wikimedia-tech list 
 Subject: Re: [Multimedia] Video output 
changing to WebM VP9/Opus soon 
Current state on this:
* delaying to mid-July so I don't start a batch process and leave it unattended 
for a week :)* still hoping to deploy the libvpx+ffmpeg backport first so we 
start with best performance; Moritz made a start on libvpx but we still have to 
resolve ffmpeg (possibly by patching 3.2 instead of updating all the way to 
3.4)* after further testing of 30fps and 60fps files, I'm also planning to 
increase the data rate a bit.
I want to do a little more testing on the ideal data rate, but it'll end up 
looking more like a 30% reduction than a 38% reduction in file size. Our 
current VP8 and provisional-VP9 configurations were tuned mostly on 24fps 
files, while 30fps files are very common and require a moderately higher data 
rate to reduce compression artifacts. (50fps and 60fps files are also around, 
and will also benefit from an increase in data rate.)
(Possibly the data rate will end up scaled according to frame rate, but frame 
rate is surprisingly hard to calculate reliably for WebM input.)
-- brion

On Sun, Jun 17, 2018 at 1:32 PM Brion Vibber  wrote:
On Sun, Jun 17, 2018 at 12:30 PM Brian Wolff  wrote:
Woo!

Good to see us moving forward to newer codecs.

:D What is the expected impact on transcode time/memory usage? (As in, will 
large videos still transcode fine or would they potentially hit limits sooner?)

Using the same CPU thread count, typical files take about 3-4 times longer with 
the configuration we've got ready. This doesn't seem to be a major problem at 
low resolutions, but higher resolutions may need to have the limits raised for 
very long videos like conference talks. Memory usage may be higher but I've not 
specifically noticed a major difference between VP8 and VP9 there.
This could be improved significantly by updating to libvpx 1.7 and a matching 
version of ffmpeg that supports macroblock row multithreading: this means that 
we'll be able to use more than 4 threads for HD videos, which should allow 
using all cores on a 20-core/40-thread machine if it's not loaded up with other 
files.
The necessary libraries are released; we just need to backport the newer 
packages to Debian 9 I believe. Don't yet know whether this will be an easy or 
hard task.
Now that you mention it I am concerned about the time limit on very long 
videos, so I'll take another look at the packaging backport and see if we can 
knock that out quickly. :)
-- brion

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

Re: [Wikitech-l] [Multimedia] Video output changing to WebM VP9/Opus soon

[Brion Vibber]

Current state on this:

* delaying to mid-July so I don't start a batch process and leave it
unattended for a week :)
* still hoping to deploy the libvpx+ffmpeg backport first so we start with
best performance; Moritz made a start on libvpx but we still have to
resolve ffmpeg (possibly by patching 3.2 instead of updating all the way to
3.4)
* after further testing of 30fps and 60fps files, I'm also planning to
increase the data rate a bit.

I want to do a little more testing on the ideal data rate, but it'll end up
looking more like a 30% reduction than a 38% reduction in file size. Our
current VP8 and provisional-VP9 configurations were tuned mostly on 24fps
files, while 30fps files are very common and require a moderately higher
data rate to reduce compression artifacts. (50fps and 60fps files are also
around, and will also benefit from an increase in data rate.)

(Possibly the data rate will end up scaled according to frame rate, but
frame rate is surprisingly hard to calculate reliably for WebM input.)

-- brion


On Sun, Jun 17, 2018 at 1:32 PM Brion Vibber  wrote:

> On Sun, Jun 17, 2018 at 12:30 PM Brian Wolff  wrote:
>
>> Woo!
>>
>> Good to see us moving forward to newer codecs.
>>
>
> :D
>
>
>> What is the expected impact on transcode time/memory usage? (As in, will
>> large videos still transcode fine or would they potentially hit limits
>> sooner?)
>>
>
> Using the same CPU thread count, typical files take about 3-4 times longer
> with the configuration we've got ready. This doesn't seem to be a major
> problem at low resolutions, but higher resolutions may need to have the
> limits raised for very long videos like conference talks. Memory usage may
> be higher but I've not specifically noticed a major difference between VP8
> and VP9 there.
>
> This could be improved significantly by updating to libvpx 1.7 and a
> matching version of ffmpeg that supports macroblock row multithreading:
> this means that we'll be able to use more than 4 threads for HD videos,
> which should allow using all cores on a 20-core/40-thread machine if it's
> not loaded up with other files.
>
> The necessary libraries are released; we just need to backport the newer
> packages to Debian 9 I believe. Don't yet know whether this will be an easy
> or hard task.
>
> Now that you mention it I am concerned about the time limit on very long
> videos, so I'll take another look at the packaging backport and see if we
> can knock that out quickly. :)
>
> -- brion
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] dumps.wikimedia.org web and rsync services down

[Bryan Davis]

On Thu, Jun 28, 2018 at 12:46 PM, Bryan Davis  wrote:
> The https://dumps.wikimedia.org web interface for downloading various
> dump files is currently offline. The rsync service for external
> mirroring is as well. Local network NFS consumers may or may not be
> working depending on which server the consumer is attached to.
>
> This unexpected outage is the result of hardware issues following a
> short planned maintenance. We are currently investigating the root
> cause of the outage and will post additional updates as they become
> available. Thanks for your patience.

All dumps.wikimedia.org services (web download, rsync mirroring, and
NFS mounts) should be back to normal working status. If you are
interested in the details of what went wrong to cause this incident
you can read  and the
followup tasks that are created for it.

Thank you again for your patience and understanding.


Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]] Manager, Cloud Services  Boise, ID USA
irc: bd808v:415.839.6885 x6855

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

[Wikitech-l] TechCom Radar 2018-06-27

[Kate Chapman]

Hi All,

Here are the minutes from this week's TechCom meeting:

* IRC meeting hosted for “Factoring page update logic out of WikiPage”

    * minutes:

    * logs:


* New RFC: RFC: Modern Event Platform - Choose Schema Tech


* Last Call (ending 2018-07-05): Provide standard-compatible way to load
multi-file packages (not plain concatenation)


* Upcoming IRC Meeting (Date and Time TBD - likely in 2 weeks) Unify
various deletion systems 

* Reviewing TechCom new member nominations

You can also find our meeting minutes at


See also the TechCom RFC board
.

If you prefer you can subscribe to our newsletter here:


Thanks,

Kate

-- 
Kate Chapman TechCom Facilitator (Contractor)

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

[Wikitech-l] dumps.wikimedia.org web and rsync services down

[Bryan Davis]

The https://dumps.wikimedia.org web interface for downloading various
dump files is currently offline. The rsync service for external
mirroring is as well. Local network NFS consumers may or may not be
working depending on which server the consumer is attached to.

This unexpected outage is the result of hardware issues following a
short planned maintenance. We are currently investigating the root
cause of the outage and will post additional updates as they become
available. Thanks for your patience.

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]] Manager, Cloud Services  Boise, ID USA
irc: bd808v:415.839.6885 x6855

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

[Wikitech-l] 2018-06-27 Scrum of Scrums meeting notes

[Grace Gellerman]

https://www.mediawiki.org/wiki/Scrum_of_scrums/2018-06-27

= 2018-06-27 =

== Callouts ==
* Fundraising campaigns
https://meta.wikimedia.org/wiki/CentralNotice/Calendar :
** 2018-07 es, 2018-07-09 to 2018-11-11 de, 2018-07-01 to 2018-11-31 en,
2018-07-10 to 2018-12-31 de, no, he, fr, nl, da, pl, ru, uk, pt, lv, ru,
ro, sk, hu, en, fr, de, zh, es
* Multi-Content Revisions: revision storage / page update rewrite (T174024,
T174038) goes live this week, RfC on further page update changes today
(T198075)

== Audiences ==
=== Readers ===
 iOS native app 
* Blocked by:
* Blocking:
* Updates:
**
 Android native app 
* Blocked by:
* Blocking:
* Updates:
** Multi-language support now in production

 Readers Web 
* Blocked by:
**Ruby to JS Cucumber refactor needs help from the RelEng team to fix our
flaky Ruby tests: https://phabricator.wikimedia.org/T190710
* Blocking:
* Updates:
**Mobile website (MinervaNeue / MobileFrontend):
***Improvements to diff T197491 T197581
***Improvements to page issues T197728 T191303
***Investigating parser cache pollution T173949
***Miscellaneous fixes and improvements T196947 T156186 T197273 T192725
T190549 T193517
***Mobile navigation for advanced contributors is in planning and design
https://www.mediawiki.org/wiki/Reading/Web/Advanced_mobile_contributions
**Desktop website (Popups):
***Miscellaneous fixes and improvements T192928 T193792 T196952 T193519
**PDF rendering (Proton):
***Miscellaneous fixes and improvements to concurrency and queue management
T186748 T186748 T186748
***Investigating grave kerning and spacing issues T178665
*Quarterly goal dependency update:
**[[metawiki:Wikimedia_Foundation_Annual_Plan/2017-2018/Draft/Programs/Product#Program_2:_Better_Encyclopedia|Outcome
1, Objective 4]]: Continue improving the ways that users can download
articles of interest for later consumption
*** Reading Web depends on SRE, RelEng, Reading Infra

 Readers Infrastructure 
* Blocked by: Ping RelEng for CI patch review:
https://gerrit.wikimedia.org/r/#/c/integration/config/+/442126/
* Blocking:
* Updates:
** Wikipedia Reading Lists extension for Safari is ready for release
** Integration of Wikimedia Page Library in the Page Content Service is in
progress — see
https://gerrit.wikimedia.org/r/#/q/topic:page-lib2+(status:open+OR+status:merged)
** Maps infrastructure handoff updates:
*** Validated loading documentation on Wikidata for new map styles (though
that work is on hold)
*** TODO: Validate loading docs for existing styles on Stretch in
preparation to upgrade the maps servers to Stretch (currently running
Jessie); pending
https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/442258/
*Quarterly goal dependency update:
**[[metawiki:Wikimedia_Foundation_Annual_Plan/2017-2018/Draft/Programs/Product#Program_2:_Better_Encyclopedia|Outcome
1, Objective 4]]: Continue improving the ways that users can download
articles of interest for later consumption
*** Reading Web depends on SRE, RelEng, Reading Infra
**[[Wikimedia Audiences/2017-18 Q4 Goals#Readers|Increase code sharing of
client apps by coalescing and moving more logic to the server]]
***Reading Infra depends on Parsing, Services

= Maps =
* Blocked by:
* Blocking:
* Updates:
** Planning on reimaging test servers to see if there are any issues
running on stretch

 Multimedia 
* Updates
** Work is progressing but tied up in administrative stuff to some extent
** Search interface prototyping currently so users can search by Wikibase
properties/values
** Also continuing work on search backend
*Quarterly goal dependency update:
**[[Wikimedia Audiences/2017-18 Q4 Goals#Programs|Objective 3.1]] Prepare
for launch of the first Structured Data on Commons feature (multilingual
file captions)
***SDC depends on Multimedia,SRE, WMDE, Search Platform, MediaWiki
Platform, Research
**  [[Wikimedia Audiences/2017-18 Q4 Goals#Programs|Objective 2.1]]
Integrate structured file captions into search
*** SDC depends on Search Platform, Multimedia
**[[metawiki:Wikimedia_Foundation_Annual_Plan/2017-2018/Final/Structured_Data#Segment_4:_Programs|Segment
4, Outcome 2]]: Develop a better understanding of existing needs for
Structured Commons- T171252
***Research depends on Multimedia

=== Contributors ===
 Community Tech 
* Blocked by:
* Blocking:
* Updates:
** Nothing new to report

 Anti-Harassment Tools 
* Blocked by:
* Blocking:
* Updates:
**

 Editing 
* Blocked by:
* Blocking:
** Updates:
**

 Parsing 
* Blocked by:
* Blocking:
* Updates:
** Language variants endpoint in production -- selectively exposed for some
languages by the REST API on the RESTBase end.
** Tidy -> RemexHtml on track for July 5th completion
*Quarterly goal dependency update:
**[[metawiki:Wikimedia_Foundation_Annual_Plan/2017-2018/Final/Programs/Product#Program_3:_Increase_device_support_for_editing|Goal
3.6]]  Support work towards unifying MediaWiki's parser implementations, in
liaison with 

Re: [Wikitech-l] [QA] CI jobs using npm might suffer from a 10 minutes delay

[Željko Filipin]

On Thu, Jun 28, 2018 at 4:42 PM David Barratt 
wrote:

> If we were to upgrade npm to 5+ (I think) that would support
> package-lock.json
>

That is discussed in https://phabricator.wikimedia.org/T179229

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

Re: [Wikitech-l] CI jobs using npm might suffer from a 10 minutes delay

[David Barratt]

If we were to upgrade npm to 5+ (I think) that would support
package-lock.json
https://docs.npmjs.com/files/package-lock.json

That file would be committed to our code repository and allow the CI to
skip the dependency resolution step(s). This means that the tar/zip or
clone would happen directly without involving registry.npmjs.org at all.

Upgrading npm (and adding a package-lock.json file) might be outside of the
scope of this issue, but I think it would help mitigate/resolve the problem.

On Thu, Jun 28, 2018 at 10:26 AM Antoine Musso  wrote:

> Hello,
>
> Since June 27th, any CI job running 'npm install' might suffer from a 10
> minutes extra delay.
>
> Somehow when requesting package informations from the NpmJS CDN
> (CloudFlare), the connection holds for ten minutes.  npm just idles
> waiting for a reply. Then eventually it shows:
>
>   npm ERR! registry error parsing json
>
> npm then retry and process as usual.
>
>
> The json error is due to a CloudFlare HTML page stating:
>
>  The page could not be rendered due to a temporary fault.
>
>
> The impact is any Jenkins job using npm have a high chance of taking 10
> more minutes to build.  That notably impacts MediaWiki core and all its
> extensions.
>
>
> A few minutes ago, I have made a change to run npm with --loglevel=info
> which would give some hints about what it is doing by causing npm to
> emit more informations in the console.  (verbose would be way too much
> log though).
>
> I have filled a bug to npm: https://github.com/npm/npm/issues/21101
> Our task: https://phabricator.wikimedia.org/T198348
>
>
> I have no idea how to mitigate the issue :-(
>
> --
> Antoine "hashar" Musso
>
>
> ___
> 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] CI jobs using npm might suffer from a 10 minutes delay

[Antoine Musso]

Hello,

Since June 27th, any CI job running 'npm install' might suffer from a 10
minutes extra delay.

Somehow when requesting package informations from the NpmJS CDN
(CloudFlare), the connection holds for ten minutes.  npm just idles
waiting for a reply. Then eventually it shows:

  npm ERR! registry error parsing json

npm then retry and process as usual.


The json error is due to a CloudFlare HTML page stating:

 The page could not be rendered due to a temporary fault.


The impact is any Jenkins job using npm have a high chance of taking 10
more minutes to build.  That notably impacts MediaWiki core and all its
extensions.


A few minutes ago, I have made a change to run npm with --loglevel=info
which would give some hints about what it is doing by causing npm to
emit more informations in the console.  (verbose would be way too much
log though).

I have filled a bug to npm: https://github.com/npm/npm/issues/21101
Our task: https://phabricator.wikimedia.org/T198348


I have no idea how to mitigate the issue :-(

-- 
Antoine "hashar" Musso


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

[Wikitech-l] Patchsets by new Gerrit contributors waiting for code review and/or merge

[Andre Klapper]

(Resurrecting the weekly posts from late 2016. Feedback welcome.)


CR0: Please review and provide guidance if you are familiar with the
code, and decide (CR±1 or CR±2):

* https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/431320/
** Trim whitespaces from the end of the text
** 2018-May-06
** Maintainers/Stewards: Contributors > Parsing team

* https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/164049/
** Add Tatar LanguageConverter
** 2018-May-24
** Maintainers/Stewards: Contributors > Parsing team

* https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/ApprovedRevs/+/434052/
** Add support for custom content types other than WikitextContent
** 2018-Jun-17
** Maintainers/Stewards: ?

* https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/PageForms/+/441021/
** edit-with-form-tab-not-displaying
** 2018-Jun-19
** Maintainers/Stewards: ?


CR+1: Please help make a decision (CR±1, CR±2) on these CR+1 patches:

* https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/ExternalData/+/421525/
** Cast the variable to an array to prevent PHP warnings
** 2018-March-23
** Maintainers/Stewards: ?


Read https://www.mediawiki.org/wiki/Gerrit/Code_review#By_project how
you can get notified of new patches in your code areas of interest.

Thanks in advance for your reviews!


Maintainers/Stewards data taken from 
https://www.mediawiki.org/wiki/Developers/Maintainers
CR0 source: 
https://gerrit.wikimedia.org/r/#/q/ownerin:newcomers+status:open+label:Verified%253D1+label:Code-Review%253D0
CR+1 source: 
https://gerrit.wikimedia.org/r/#/q/ownerin:newcomers+status:open+label:Verified%253E%253D1+label:Code-Review%253E%253D%252B1+-label:Code-Review%253C%253D0

-- 
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/


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