Wikitech-l February 2015

wikitech-l@lists.wikimedia.org

134 participants
140 discussions

[gerrit] EUREKA!
by Brian Gerstle 09 Feb '15

09 Feb '15

Go to a change <https://gerrit.wikimedia.org/r/#/c/187879/3>, click on the gitbit <https://git.wikimedia.org/commit/apps%2Fios%2Fwikipedia/6532021b4f4b1f09390…> link next to a patch set, then behold: MAGIC!!! <https://git.wikimedia.org/commitdiff/apps%2Fios%2Fwikipedia/712f033031c3c11…> GitHub like diff viewer! No more "All Side-by-Side" w/ 1e6 tabs open. Enjoy! Brian -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle

6 8

Extensions licensing
by Ricordisamoa 08 Feb '15

08 Feb '15

Hi! As some of you may have noticed, I am currently promoting the clarification of several extensions' licenses. Specifically, every MediaWiki extension should register itself with one of the SPDX-compliant license codes <http://spdx.org/licenses/> and include a valid FOSS license as a file whose name matches the pattern "^((COPYING)|(LICENSE))(\.txt)?$". As part of this process, Gerrit change 187178 <https://gerrit.wikimedia.org/r/187178/> was merged causing license files to be shown in raw format, and a request for bot flagging <https://www.mediawiki.org/wiki/Project:Requests/User_rights/SamoaBot> was filed to speed up the conversion of extension pages. Then, more than 80 patches were filed against extension repos (mostly with "license-name" as topic) and merged with help from maintainers. This first batch of updates is almost complete, so I'd like to thank Kunal Mehta, Siebrand Mazeland, Luis Felipe Schenone, Santhosh Thottingal, Thiemo Mättig, Marius Hoch, Tony Thomas, Peter Coombe, Antoine Musso, Max Semenik, Umherirrender, PleaseStand, He7d3r, Niklas Laxström, Federico Leva, Bartosz Dziewoński, Gilles Dubuc, Thomas Pellissier Tanon, Jon Robson, Florian Schmidt, Brad Jorsch and Timo Tijhof (in no particular order) for their valuable support. However, several repositories are still lacking license information completely, or have inaccurate notices. I'd suggest to create a Phabricator project/tracking task to manage licensing issues across the codebase.

3 4

Fwd: AW: jenkings merging
by Florian Schmidt 07 Feb '15

07 Feb '15

Damn, forwarding to wikitech-l, forget to click the answer all button :( Von: Florian Schmidt [mailto:florian.schmidt.welzow@t-online.de] Gesendet: Samstag, 7. Februar 2015 13:29 An: 'Thomas Mulhall' Betreff: AW: AW: [Wikitech-l] jenkings merging Ah, ok. Maybe a little bit background for this: Git is a decentral version manageing tool (basically). Gerrit allows you to review changes before you commit it into your git repository. Now an example: Developer A push a change for review to gerrit (based on the actual master). Developer B push a change for review to gerrit, too (again based on actual master branch). Say, Developer C reviews change from Developer B and +2 it (or set +2, Verified and submit the change). Jenkins will run gate and submit jobs and will trigger gerrit to merge the commit into the git repository. The change will, because it is directly based on master, just be merged and master fast forwarded to the new commit. | master | change from developer B | old master Now, Developer C reviews the change of Developer A and +2 it, too. Now we have a problem. The change based on an older version of the master branch, maybe this graphic helps you to understand it: | master | change from developer B | | change from developer A |/ | old master So, the change from developer A (which is, in fact, a new branch in git) has to be merged into the actual master. In general, gerrit can do this alone (if there are no merge conflicts) which will result in the following history: | new master |\ “Merge change from developer B” | | old master | | change from developer B | | change from developer A |/ | old, old master So, merging is only needed, if you submit a change, which is based on an older master. This will be, if you submit a change, which wasn’t rebased to the actual master and there were other changes submitted before it. In general, this will be in projects with more than one developer (because more developers: more commits and more submitted changes), or if you’re upload a change for review, working on other changes and submit them, and review your first change after it without rebasing. If you have a look at your project: all changes are based on the actual master and submitted without any other change submitted before it, so you have a nice linear git history :D If a merge is needed sometimes, gerrit will do it without any new setup/configuration. Hope that helps and excuse some little faults I maybe made somewhere in this mail :) Kind regards, Florian Von: Thomas Mulhall [mailto:thomasmulhall410@yahoo.com] Gesendet: Samstag, 7. Februar 2015 13:02 An: Florian Schmidt; 'Wikimedia developers' Betreff: Re: AW: [Wikitech-l] jenkings merging Like this <https://git.wikimedia.org/commit/mediawiki%2Fextensions%2FCentralAuth/13e92…> https://git.wikimedia.org/commit/mediawiki%2Fextensions%2FCentralAuth/13e92… On Saturday, 7 February 2015, 12:01, Thomas Mulhall < <mailto:thomasmulhall410@yahoo.com> thomasmulhall410(a)yahoo.com> wrote: Jenking does it as a commit of its own. On Saturday, 7 February 2015, 12:01, Thomas Mulhall < <mailto:thomasmulhall410@yahoo.com> thomasmulhall410(a)yahoo.com> wrote: Hi what I mean is on centralauth jenking says merged this branch. I would like to do that too please. On Saturday, 7 February 2015, 11:53, Florian Schmidt < <mailto:florian.schmidt.welzow@t-online.de> florian.schmidt.welzow(a)t-online.de> wrote: Hi Thomas, what do you want to do? If you upload a new patchset to a change (or a new change), Jenkins will automatically merge this change with the master branch and runs tests against the resulting artifact :) That's what I know. Kind regards Florian -----Ursprüngliche Nachricht----- Von: wikitech-l-bounces(a)lists.wikimedia.org <mailto:wikitech-l-bounces@lists.wikimedia.org> [mailto:wikitech-l-bounces@lists.wikimedia.org <mailto:wikitech-l-bounces@lists.wikimedia.org> ] Im Auftrag von Thomas Mulhall Gesendet: Samstag, 7. Februar 2015 01:56 An: Wikimedia developers Betreff: [Wikitech-l] jenkings merging Hi how do I get my skins and extensions to be merged automatically by jenkings like it does on centralauth projects are at https://git.wikimedia.org/summary/mediawiki%2Fskins%2FMetrolook <https://git.wikimedia.org/summary/mediawiki%2Fskins%2FMetrolook> and https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FCollapsibleVector <https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FCollapsibleVector> _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org <mailto:Wikitech-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 0

Re: [Wikitech-l] Phabricator search
by Erik Moeller 07 Feb '15

07 Feb '15

On Thu, Feb 5, 2015 at 7:50 PM, MZMcBride <z(a)mzmcbride.com> wrote: > Perhaps if Titan/Wikidata Query Service development is on hold, Nik could > investigate this? Not really on hold - just looking at alternatives to Titan. But this is a pretty critical issue for all our dev workflows, so really would appreciate help from our search gurus in resolving it. Erik -- Erik Möller VP of Product & Strategy, Wikimedia Foundation

2 1

New "Reference Tooltips" beta feature
by Ricordisamoa 07 Feb '15

07 Feb '15

Hi everyone, I've come up with a rough OOjs-UI-based rewrite of the long-standing Reference Tooltips <https://www.mediawiki.org/wiki/Reference_Tooltips> gadget. I'd like to see it enabled on Wikimedia sites as a beta feature, to ultimately replace the gadget, but I'm not sure it is worth an extension on its own. It could share some code with the Popups extension <https://www.mediawiki.org/wiki/Extension:Popups> but, unlike the latter, the former does not depend on neither TextExtracts nor PageImages. The Cite extension <https://www.mediawiki.org/wiki/Extension:Cite> is required for references to work, so the tooltips could just be an additional feature. However, I don't feel comfortable with embedding such an experiment into a cornerstone of ours like Cite. VectorBeta <https://www.mediawiki.org/wiki/Extension:VectorBeta> includes many features of this kind, but reference tooltips are really not Vector-specific. Which do you think is the most suitable repository?

4 9

Tool on labs for replacing old username signatures
by Keegan Peterzell 07 Feb '15

07 Feb '15

When users are renamed, it is up to the user to find and replace all old instances of their signature to make sure that they redirect to the appropriate account if they want to put that much work into. The other option is the re-register your old username and redirect it to the new one. This is not feasible all the time, for instance if someone owns the SUL to the old username and comes over to take it before it gets re-registered. I was wondering if anyone had the interest to build a tool on labs that would let a renamed user find-and-replace old signatures in an automated fashion? The tool would check against the rename log and the old timestamp to make sure it's the appropriate user, and substitute the old name part with ~~~ to insert the new username while preserving the timestamp. I'm not a developer my self, so thoughts on feasibility and implementation are welcome. I think such a tool would be highly useful and I'm slightly surprised it hasn't been made yet. -- Keegan Peterzell Community Liaison, Product Wikimedia Foundation

5 5

Roadmap and deployment updates - week of Feb 9th
by Greg Grossmeier 07 Feb '15

07 Feb '15

Hello and welcome to the latest edition of the WMF Engineering Roadmap and Deployment update. The full log of planned deployments next week can be found at: <https://wikitech.wikimedia.org/wiki/Deployments#Week_of_February_9th> A quick list of notable items... (not much) == Tuesday == * MediaWiki deploy ** group1 to 1.25wmf16: All non-Wikipedia sites (Wiktionary, Wikisource, Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites) ** <https://www.mediawiki.org/wiki/MediaWiki_1.25/wmf16> == Wednesday == * MediaWiki deploy ** group2 to 1.25wmf16 (all Wikipedias) ** group0 to 1.25wmf17 (test/test2/testwikidata/mediawiki) Thanks and as always, questions and comments welcome, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

Re: [Wikitech-l] Phabricator search
by Bryan Davis 07 Feb '15

07 Feb '15

On Thu, Feb 5, 2015 at 8:50 PM, MZMcBride <z(a)mzmcbride.com> wrote: > Hi. > > Phabricator search is currently pretty bad: > <https://phabricator.wikimedia.org/T75854>. > > We should already be wary of putting all our eggs in the Phabricator > basket. Search is hugely important to an issue tracker and code > repository, so if we're going to continue growing Phabricator, we need to > figure out short-term and long-term solutions for Phabricator search. > > Perhaps if Titan/Wikidata Query Service development is on hold, Nik could > investigate this? Or perhaps dropping Elasticsearch for now in favor of > the built-in search would be better? Thoughts, suggestions, etc. welcome. ^d was looking into this a bit today based on some reports that came in on irc. He's been working actively with the upstream to make their Elasticsearch integration better already and is now assigned to the Release Engineering team that helped bootstrap the Phabricator install so I'd expect he will continue to be interested in improvements. Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

2 1

Video Uploads to Commons
by Nkansah Rexford 06 Feb '15

06 Feb '15

I couldn't find a tool to convert my videos from whatever format into .ogv outside my PC box before pushing to Commons. I guess there might exist something like that, but perhaps I can't find it. But I made one for myself. Maybe it might be useful to others too. I call it CommonsConvert. Upload any video format, enter username and password, and get the video converted into .ogv format plus pushed to Commons all in one shot. You upload the original video in whatever format, and get it on Commons in .ogv Some rough edges currently, such as can't/don't know/no available means to append license to uploaded video among other issues. Working on the ones I can asap. It uses mwclient module via Django based on Python. Django gives user info to Python, Python calls avconv in a subprocess, and the converted file is relayed to Commons via mwclient module via Media Wiki API. I think not everyone has means/technical know how/interest/time converting videos taken on their PC to an Ogg-Vorbis-whatever format before uploading to Commons. Doing the conversion on a server leaves room for user to focus on getting videos than processing them. I don't know if this is or will be of any interest that someone might wanna use, but I personally would enjoy having a server sitting somewhere convert my videos I want to save onto Commons, than using my local computer doing that boring task. In an email to this list a week or so ago, I 'ranted' about why commons wants a specific format (which if not for commons, I never come across that format anywhere), but has no provision for converting any videos thrown at it into that format of its choice. Well.... Tool can be found here: khophi.co <http://khophi.co/commonsconvert>/ <http://khophi.co/commonsconvert>commonsconvert <http://khophi.co/commonsconvert> And this is sample video uploaded using the tool. https://commons.m.wikimedia.org/wiki/File:Testing_file_for_upload_last.ogv (will be deleted soon, likely) What I do not know or have not experimented yet is whether uploading using the api also has the 100mb upload restriction. Will appreciate feedback.

8 10

Permanently deleting change tags available by default
by Jackmcbarn 06 Feb '15

06 Feb '15

Gerrit change 181958[1] was recently merged, which allows (among other things) the ability for sysops to irrecoverably delete change tags. Since irrecoverable deletion of anything from on-wiki is rather unprecedented, I think we should stop granting it to all sysops in DefaultSettings.php, so that wikis have to "opt-in" for this feature to be enabled. Thoughts? [1]https://gerrit.wikimedia.org/r/#/c/181958/

5 9

← Newer
1
...
8
9
10
11
12
13
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 February 2015