Hello Everyone,
This is Jay. I have some questions and want to know that it is possible to
apply on the ground.
== Problems ==
* I work on the very trivial tasks. and even after working on the very
trivial tasks, sometimes my patch does not merge even after 6 months has
passed. Recently I have Abandoned my some patches due to be not merged
after 6 months has passed.[1][2]
* Recently there are many tasks created on phab to Archive the
extensions. Those
extensions have not maintained in the last 5 years.
* And also We have lack of peoples for reviewing those extension's patches,
which have not deployed on Wikimedia or any other big wiki.
== Potential Solution ==
The potential solution is to create a new group on the Gerrit with +2
rights. This group will manage those extensions which have not maintained
by the owner in last 1 year (if not, Maybe 2 years). This will save the
extension from being unmaintained. There are many users who have good
knowledge and They review patches like Mainframe98,[3] MGChecker, and
others.
So my question is why does we not create this type of group? so that users
can managed those extensions which have not maintained in last 1 year.
[1]
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/LanguageTag/+/40605…
[2] https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Arrays/+/405057/
[3]
https://gerrit.wikimedia.org/r/#/q/reviewedby:%22Mainframe98+%253Ck.s.werf%…
Thanks
Reminder: Technical Advice IRC meeting again **Wednesday 3-4 pm UTC** on
#wikimedia-tech.
The Technical Advice IRC Meeting (TAIM) is a weekly support event for
volunteer developers. Every Wednesday, two full-time developers are
available to help you with all your questions about Mediawiki, gadgets,
tools and more! This can be anything from "how to get started" over "who
would be the best contact for X" to specific questions on your project.
In addition to the weekly meeting at 3 pm, we will have an additional
meeting every first Wednesday of the month at 11 pm UTC, starting August
1st, 2018!
If you know already what you would like to discuss or ask, please add your
topic to the next meeting:
https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting
Hope to see you there!
Michi (for WMDE’s tech team)
--
Michael F. Schönitzer
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Thanks to all people involved,
I just read about this new video format in the making/released [0].
Of course, I am not asking to support this, as this seems like the future,
and not the present, but being a complete noob on video formats and codecs,
I would like to know if someone more knolegeble has some insight about this
and if it is something to keep in mind/someone has tested it and has
experiences to share/client and vendor support?
--
Jaime
[0] <url:
https://blog.mozilla.org/blog/2018/07/11/royalty-free-web-video-codecs/>
On Fri, Jun 29, 2018 at 6:46 PM, Brion Vibber <bvibber(a)wikimedia.org> wrote:
> Awesome sauce. Thanks Moritz!
>
> -- brion
>
> On Fri, Jun 29, 2018 at 7:39 AM Moritz Muehlenhoff <
> mmuhlenhoff(a)wikimedia.org> wrote:
>
> > Hi all,
> >
> > On Thu, Jun 28, 2018 at 01:54:18PM -0700, Brion Vibber wrote:
> > > Current state on this:
> > >
> > > * still hoping to deploy the libvpx+ffmpeg backport first so we start
> > with
> > > best performance; Moritz made a start on libvpx but we still have to
> > > resolve ffmpeg (possibly by patching 3.2 instead of updating all the
> way
> > to
> > > 3.4)
> >
> > I've completed this today. We now have a separate repository component
> > for stretch-wikimedia (named component/vp9) which includes ffmpeg 3.2.10
> > (thus allowing us to follow the ffmpeg security updates released in
> Debian
> > with a local rebuild) with backported row-mt support and linked against
> > libvpx 1.7.0.
> >
> > I tested re-encoding
> >
> > https://commons.wikimedia.org/wiki/File:Wall_of_Death_-_
> Pitts_Todeswand_2017_-_Jagath_Perera.webm
> > (which is a nice fast-paced test file) from VP8 to VP9, which results in
> > a size reduction from 48M to 31M.
> >
> > When using eight CPU cores on one of our video scaler servers, enabling
> > row-mt
> > gives a significant performance boost; encoding time went down from 5:31
> > mins
> > to 3:36 mins.
> >
> > All the details can be found at
> > https://phabricator.wikimedia.org/T190333#4324995
> >
> > Cheers,
> > Moritz
>
Hello,
The ArticlePlaceholder extension has QUnit tests run via nodejs. I am
trying to port them to Special:JavaScriptTest.
I am hitting a wall due to an OOUi widget not being found on the first
test. Most probably because the window is opened asynchronously and the
assertions are run before it opens.
JavaScript Promises are not my thing and I know nothing about OOUi. If
that is in your area of expertise, I could use a hand to finish up the port:
https://gerrit.wikimedia.org/r/#/c/444936/6
Thank you!
--
Antoine "hashar" Musso
Hi all,
It seems the Common.css on my website is pretty small but Resource Loader
loads it using a <link> tag in the head. I have read that it will be better
to instead inline the styles or even load them later.
What is the right way to go about this?
Any suggestions are welcome.
Also see
https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery
Regards,
Nischay Nahata
Good morning!
The pages-meta-history dumps for hewiki take 70 hours these days, the
longest of any wiki not already running with parallel jobs. I plan to add
it to the list of 'big wikis' starting August 1st, meaning that 6 jobs will
run in parallel producing the usual numbered file output; look at e.g.
frwiki dumps for an example.
Please adjust any download/processing scripts accordingly.
Thanks!
Ariel
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