Wikitech-l August 2014

wikitech-l@lists.wikimedia.org

133 participants
137 discussions

mediawiki now being tested with vendor repo
by Antoine Musso 26 Aug '14

26 Aug '14

Hello, We have a mediawiki/vendor repository that holds third party libraries. Since MediaWiki core is going to eventually rely on them I have crafted a new Jenkins job (mediawiki-vendor-integration) which clones both repositories, checkout the appropriate patch / branch and run the whole MediaWiki PHPUnit test suite. The job is triggered when a patch is proposed on either mediawiki/core or mediawiki/vendor but only for the master and REL* branches for now. I have made it non voting. The job takes roughly 6 minutes that will slightly delay the report to Gerrit. If the job looks fine. The next steps are: - make it pass on wmf branches - trigger it run on CR+2 Then, I will be able to phase out the grouped PHPUnit groups and the sqlite installer tester. Long term: have the tests to run using HHVM as well. -- Antoine "hashar" Musso

3 4

build.wikimedia.org
by Quim Gil 26 Aug '14

26 Aug '14

(This is the project formerly known as Wikimedia Data & Developer Hub) build.wikimedia.org aims to become a hub for developers and researchers interested in Wikimedia data and the APIs to interact with it. Wikimedia has developed a number of repositories of free and open datasets, and has made its APIs freely available. However, these APIs and their documentation are currently scattered across several projects, with no central location for people to learn about and build upon them. Let's fix this problem! Wikimedia has so much to offer. https://www.mediawiki.org/wiki/build.wikimedia.org http://fab.wmflabs.org/project/board/60/ Currently we are developing a prototype.[1] We are still discussing the technologies to be used in the final implementation,[2] including the specific use of MediaWiki. Your ideas and help are welcome. 1 - http://fab.wmflabs.org/T478 2 - http://fab.wmflabs.org/T491 -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

5 4

Make port 22 on gerrit.wikimedia.org default for git (same as what 29418 is now)
by Petr Bena 26 Aug '14

26 Aug '14

gerrit.wikimedia.org is a default git gateway for all of wikimedia projects, but it still has a number of issues compared to other (IMHO better) providers, like GitHub. One of major issues I am now having is, that git needs to be accessed using non-standard port because regular ssh access is still being served on port 22. This is a problem on restricted networks where random ports are prohibited and blocked for various reasons, while standard ports like 21, 22, 80 etc are open. I propose to move the current ssh port (22) to some non-standard port, as staff which needs to use it is far smaller than developer community that needs to access git (the server itself is for git only) and open port 22 as a gerrit (git) port. The current port 29418 can be used as well, so that nobody needs to update their repo's which were already cloned. This is technically possible and I think it would make usage of gerrit much less of a pain in the ****. Thanks for your considerations :P

2 1

planned move to phabricator
by svetlana 26 Aug '14

26 Aug '14

Hi all. I am reading https://www.mediawiki.org/wiki/Phabricator/Migration and it says: "A review of our project management tools [1] was started, including an assessment of our needs and requirements, and a discussion of available options. A request for comment [2] was set up to gauge interest in simplifying our development toolchain and consolidating our tools (gitblit, Gerrit, Jenkins, Bugzilla, RT, Trello, and Mingle) into Phabricator. The result of the RFC was in favor of Phabricator." The RFC linked is https://www.mediawiki.org/wiki/Requests_for_comment/Phabricator . It is clearly put wrong. People were not given alternatives. They were told "let's move to Phabricator" and they said "OK, let's do that". I am frustrated. Decide on X, open a "let's do X", get support - this is not how decisions are done. Would anyone oppose me writing another RFC detailing all the available options (including staying with bugzilla and what cons it has) and posting an URL to it here? svetlana [1] https://www.mediawiki.org/wiki/Project_management_tools/Review [2] https://www.mediawiki.org/wiki/Project_management_tools/Review

7 14

MassMessage delivery list improvement (GSoC wrap-up)
by wctaiwan 25 Aug '14

25 Aug '14

Hi, For my Google Summer of Code project, I worked on improving the way delivery lists are stored and modified in the MassMessage extension.[1] To that end, I have implemented a ContentHandler and JSON-based backend for storing delivery lists, in addition to frontend for creating and managing the lists. Compared to my stated deliverables, I have largely accomplished what I set out to do, with the following being the larger differences: * For editing lists, instead of an interface similar to the prototype linked on the project page with a no-JavaScript fallback, I implemented a more Wikidata-like UI for quick additions and removals. * Instead of an API for adding or removing own talk pages from delivery lists, I worked on a more general API for adding and removing pages. The code has yet to be merged or deployed, pending some final code review and database changes for WMF wikis,[2] but it should be doable in the near future. In the meantime, there is a Labs instance set up running the new code;[3] please try it out and provide any feedback. I’d like to thank Legoktm for being an extremely helpful and responsive mentor, Prtksxna for his UX guidance and help, and MZMcBride for testing the new features and pointing out issues and things to improve. Working on the project has been a valuable experience, and I appreciate all the assistance I received that helped make it a success. wctaiwan [1] http://www.mediawiki.org/wiki/Extension:MassMessage/Page_input_list_improve… [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=49193 [3] http://mm-ch.wmflabs.org/

2 1

Bugzilla Weekly Report
by reporter＠zirconium.wikimedia.org 25 Aug '14

25 Aug '14

1 0

Arlo Breault joins Wikimedia as Features Engineer
by Terry Chay 24 Aug '14

24 Aug '14

Hello everyone, It’s with great pleasure that I’m announcing that Arlo Breault joined the Wikimedia Foundation as a Features Engineer. Note the past tense. :-D Before joining us, Arlo worked as an independent open-source software developer. He’s held various contracts at the Tor Project[1], DuckDuckGo[2], Storify[3], and Right & Democracy[4], amongst others, where he’s worked on everything from novel censorship circumvention systems to navigable visualizations of the web graph. I first found out about him in April of 2012, but we only managed to find a fit a year ago in July of 2013 as an international contractor. His first official day as a member of our staff was July 7, 2014. I tell myself that announcing Arlo and Marc together is the reason I’ve been tardy on these announcements. :-D Along with Marcoil (previous e-mail), the two of them work with Subbu Sastry and C. Scott Ananian to form the Parsoid team, which provides the back-end voodoo that turns your VisualEditing into wikitext and back again.[5] Arlo studied physics and mathematics at McGill in Montréal, and now lives in Victoria, BC. He has been spending a lot of his free time lately looking at cryptographic protocols, contributing OTR.js[6] to Cryptocat[7], a privacy preserving chat application. He’s otherwise typically Canadian, enjoying his maple syrup, hockey, and reading by the warm glow of a fire. Please join me in a belated welcome of Arlo to the Wikimedia Foundation. :-) Take care, Terry P.S. In keeping with Jared’s demand of a picture to accompany every new hire announcement, here is one: https://avatars0.githubusercontent.com/u/123708?v=2&s=400 [1] https://www.torproject.org/ [2] https://duckduckgo.com/ [3] https://storify.com/ [4] https://en.wikipedia.org/wiki/International_Centre_for_Human_Rights_and_Dem… [5] https://blog.wikimedia.org/2013/03/04/parsoid-how-wikipedia-catches-up-with… [6] https://github.com/arlolra/otr [7] https://crypto.cat/ terry chay 최태리 Director of Features Engineering Wikimedia Foundation “Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.” p: +1 (415) 839-6885 x6832 m: +1 (408) 480-8902 e: tchay(a)wikimedia.org i: http://terrychay.com/ w: http://meta.wikimedia.org/wiki/User:Tychay aim: terrychay

3 2

Reviewing a couple of TorBlock patches
by Quim Gil 24 Aug '14

24 Aug '14

According to our algorithm (*), TorBlock currently has the worse track reviewing code contributions -- even after Tim gave a -1 to one of the three open patches last week (thanks!). There are two patches from Tyler that haven't received any feedback at all since August 2013. https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions… Your help reviewing these patches is welcome. It is not surprising that this extension has no maintaner listed at https://www.mediawiki.org/wiki/Developers/Maintainers (someone suggested Tim in that table, he disagrees and edited accordingly). Also, maybe someone is interested in maintaining this extension? Only eleven patches submitted in the last 15 months. (*) http://korma.wmflabs.org/browser/gerrit_review_queue.html -- the algorithm happens to be buggy these days, but apparently equally buggy for all repos, which still results in some kind of justice. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

4 3

Thoughts about roles
by Max Semenik 23 Aug '14

23 Aug '14

Currently a lot of our extension Vagrant roles are working like Swiss knives: they do everything possible to imagine. For example, MobileFrontend always installs 3 optional dependencies while CirrusSearch includes its configuration for unit tests that among other things enforces $wgCapitalLinks = false which is untypical for most MW installs. I think many of these actually make development harder. Solution? Can we split some larger roles to "basic" and "advanced" parts, so that people who need an extension to play around or to satisfy a dependency will not be forced to emulate a significant part of WMF infrastructure? -- Best regards, Max Semenik ([[User:MaxSem]])

7 7

Extension idea
by John 23 Aug '14

23 Aug '14

How feasible would it be to enable file access/linking to files on a given filesystem without having to upload them? Use case, I have a documentation system in /server/docs which I provide access internally via a file share to all users. However remote users are unable to access that share. How difficult/dangerous would it be to to have an extension that provided access to those files for our remote users.

2 1

← Newer
1
2
3
4
5
6
7
8
...
14
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l August 2014