Re: [Wikitech-l] MediaWiki Language Extension Bundle 2014.11 release
2014-12-01 8:41 GMT+02:00 David Chamberlain da...@alaskawiki.org: I run 5 wikis for a total of 6,000 pages and still use solr in 6 languages. Thanks for the information, David. We will keep the code for Solr backend. -Niklas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phabricator migration part II: Replacing gitblit with Diffusion
On Thu, Nov 27, 2014 at 3:02 PM, Merlijn van Deen valhall...@arctus.nl wrote: I've fiddled a bit with this in the style of tail numbers / actual radio call signa: first letter is a category (country in a call sign), the rest is assigned as a number, unless someone wants a specific one. The other day some of us were discussing something along these lines on IRC;[1] unfortunately that doesn't seem to have made it to the mailing list. We wound up liking something very similar to this, except we skipped the unless someone wants a specific one part. Always randomly assigning the number for everyone means no worry over conflicts. [1]: http://bots.wmflabs.org/~wm-bot/logs/%23mediawiki-core/20141126.txt starting around 15:27 Categories: AN - analytics AP - apps CI - integration LT - labs/tools PH - phabricator PW - pywikibot IMO it would be nice if the categories could all be the same length instead of some being one character and some being two. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phabricator migration part II: Replacing gitblit with Diffusion
On Sat, Nov 29, 2014 at 6:26 PM, Merlijn van Deen valhall...@arctus.nl wrote: - The G-prefix has on major advantage: it keeps the 'root namespace' (i.e. the first letter) clean: at the moment only A C E G L M O P S W are in use, so adding another prefix 'B' is easy. If we already have repositories that start with a B, it's more confusing. +1 -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Google Code-in 2014 has begun! We want your tasks!
Google Code-in 2014 has started a few hours ago and the first Wikimedia tasks got claimed and being worked on by students! GCI will run until January 19. Students are eager and tasks get claimed quickly. If you have not become a mentor yet: WE WANT YOU TO BECOME A MENTOR AND ADD MORE TASKS! * Provide 3 easy Phab tasks in your area that you could mentor * OR: provide an easy clonable task (a type of task that is generic and could be repeated many times - for example, Language Engineering has several GCI tasks to write a help page for one uncovered input method in ULS and the student has to choose and mention the one input method s/he's going to work on) * The tasks must include instructions and point to documentation * You commit to answer to students' questions and to evaluate their work within 36 hours (the better your task description the less questions you get. And no worries, we're there to help you! ) Please check out https://www.mediawiki.org/wiki/Google_Code-in_2014#Mentors.27_corner - Don't hesitate to ask questions if something is unclear! Thank you for giving young contributors the opportunity to learn about and work on Free and Open Source Software projects! 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
Re: [Wikitech-l] Phabricator outage due to network issues, 11/29
Hi, let me recycle this reply posted initially at Determine phabricator.wikimedia.org service level - https://phabricator.wikimedia.org/T76381 Currently Phabricator is getting the same service level that Bugzilla had. Looking at the whole Wikimedia picture, I think this is the most sensible option. I don't see any strong reason to change it. Bugzilla was down unexpectedly several times in the past years, and if Ops was able to react quicker it's just because we were luckier with the cause, timing and location of the breaks. If we would have Bugzilla instead of Phabricator in the rack that went down this weekend, the service provided by Ops would have been exactly the same. We can reopen this discussion when planning the migration of code review and (eventually) continuous integration. For now, I think we are good. This is the opinion of the Engineering Community team. If this works also for Operations and Platform Engineering, then we can resolve this task. PS: About the downtime itself, 5 hours on a weekend is clearly unfortunate, but imho nothing that should make us revise the current service level. Was anybody unable to work, arms crossed? Was any project delayed? I'm counting volunteers as much as employees. Personally I learned about the downtime only in wikitech-l, having used Phabricator on Saturday-Sunday night at 1am CET, and then on Sunday at 1pm. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Google Code-in 2014 has begun! We want your tasks!
Google Code-in 2014 has started a few hours ago and the first Wikimedia tasks got claimed and being worked on by students (one task already has a patch in Gerrit)! GCI will run until January 19. Students are eager and tasks get claimed quickly. If you have not become a mentor yet: WE WANT YOU TO BECOME A MENTOR AND ADD MORE TASKS! * Provide 3 easy Phab tasks in your area that you could mentor * OR: provide an easy clonable task (a type of task that is generic and could be repeated many times - for example, Language Engineering has several GCI tasks to write a help page for one uncovered input method in ULS and the student has to choose and mention the one input method s/he's going to work on) * The tasks must include instructions and point to documentation * You commit to answer to students' questions and to evaluate their work within 36 hours (the better your task description the less questions you get. And no worries, we're there to help you!) Please check out https://www.mediawiki.org/wiki/Google_Code-in_2014#Mentors.27_corner - Don't hesitate to ask questions if something is unclear! Thank you for giving young contributors the opportunity to learn about and work on Free and Open Source Software projects! 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] Scribunto will no longer reveal the HTML behind strip markers in 1.25wmf11
The original request behind Scribunto's mw.text.unstrip method was to undo nowiki tags, as a mechanism for quoting arguments being passed into a module. But the implementation was more broad, allowing access to the HTML generated by the ref and references tags, by special page transclusion, and so on. This caused problems such as T63268.[1] With the merge of Gerrit change 171290,[2] the mw.text.unstrip method will unstrip nowiki strip markers and will replace all other strip markers with the empty string. A new method mw.text.unstripNoWiki is also provided to unstrip nowiki markers while leaving other markers in place, and mw.text.killMarkers to remove all strip markers from a string. Modules using mw.text.unstrip should be checked to ensure they don't break with this change. A list of modules on WMF wikis including the string unstrip is at https://test.wikipedia.org/wiki/User:Jackmcbarn/unstrip. See https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap for the deployment schedule. [1]: https://phabricator.wikimedia.org/T63268 [2]: https://gerrit.wikimedia.org/r/#/c/171290/ -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Final RC for 1.24
On 11/26/2014 08:57 AM, Mark A. Hershberger wrote: Matthew Flaschen mflasc...@wikimedia.org writes: This brings up a question. Where is the code that builds the tarball? The script is make-release/make-release.py in the mediawiki/tools/release[1] repository. Thanks for the info. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Local cherry-picks missing on deployment-salt
Adding wikitech-l On Mon, Dec 1, 2014 at 2:59 PM, Greg Grossmeier g...@wikimedia.org wrote: tl;dr: Testing on deployment-salt (or other Beta Cluster/deployment-prep vms?): please watch out for [LOCAL HACK] commits and don't lose them. See: https://phabricator.wikimedia.org/T75947 Basically: Some local puppet changes were committed on deployment-salt with [LOCAL HACK] in the summary (as is the practice to test/do things before they're merged in ops/puppet for a number of reasons, see: https://phabricator.wikimedia.org/T76392 for reducing that). They were, unfortunately lost somehow. Current theory is that someone accidentally clobbered them while doing their own testing. If it was you, no worries (Bryan's already fixed this specific case, thanks Bryan!) but please don't do it again. :) Feel free to talk with the QA mailing list if you have any questions on how to do testing of puppet changes in Beta Cluster: https://lists.wikimedia.org/mailman/listinfo/qa Best, Greg -- Greg Grossmeier Release Team Manager -- Greg Grossmeier Release Team Manager ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Local cherry-picks missing on deployment-salt
On Mon, Dec 1, 2014 at 4:17 PM, Greg Grossmeier g...@wikimedia.org wrote: Adding wikitech-l On Mon, Dec 1, 2014 at 2:59 PM, Greg Grossmeier g...@wikimedia.org wrote: tl;dr: Testing on deployment-salt (or other Beta Cluster/deployment-prep vms?): please watch out for [LOCAL HACK] commits and don't lose them. See: https://phabricator.wikimedia.org/T75947 Basically: Some local puppet changes were committed on deployment-salt with [LOCAL HACK] in the summary (as is the practice to test/do things before they're merged in ops/puppet for a number of reasons, see: https://phabricator.wikimedia.org/T76392 for reducing that). They were, unfortunately lost somehow. Current theory is that someone accidentally clobbered them while doing their own testing. If it was you, no worries (Bryan's already fixed this specific case, thanks Bryan!) but please don't do it again. :) Feel free to talk with the QA mailing list if you have any questions on how to do testing of puppet changes in Beta Cluster: https://lists.wikimedia.org/mailman/listinfo/qa Best, Greg On any given day there are generally quite a few cherry-picked commits on deployment-salt that are being tested and used in the beta cluster prior to being merged into the shared operations/puppet.git repo that powers puppet for labs in general, the beta project (deployment-prep) and our production hosts. At the moment I'm writing this, the list looks like this: deployment-salt:/var/lib/git/operations/puppet (git production $) bd808$ git log --color --pretty=oneline --abbrev-commit origin/HEAD..HEAD 3353137 logstash: Forward syslog events for apache2 + hhvm ace40a2 Use hiera to configure udp2log endpoint for ::mediawiki dc11da3 logstash: Rules for processing MW input via Redis 22837cd Configure Logstash and Elasticsearch for ApiFeatureUsage 53d8b58 Change eventlogging log dir bbaa10b eventlogging: couple less tightly to ganglia 48f60fa Fix Parsoid in beta 1d58f04 Get betalabs localsettings.js file from deploy repo (just like prod) 4e03e67 Allow puppetmaster to send reports to logstash caef989 [LOCAL HACK] T67591: User['mwdeploy'] shell = /bin/bash a22bbec [LOCAL HACK] T47706 Change MySQL admin user in sql script There is a pretty good write up on wikitech [0] on the safe process for adding a new cherry-pick to the beta puppet master and removing one that is no longer wanted. I'd be glad to help anyone who has questions or problems with the process as well. [0]: https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/How_code_is_updated#Cherry-picking_a_patch_from_gerrit Bryan -- Bryan Davis Wikimedia Foundationbd...@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software EngineerBoise, 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] Visibility of action in API for deleted log entries
Hi list, I wanted to get some feedback about https://phabricator.wikimedia.org/T74222. In the last security release, I changed the return of the api to remove the action for log entries that had been revdeleted with Hide action and target. However, ever since 2009 / r46917, we've assumed that Hide action and target didn't mean the actual action field in the db, but rather the target and the text of the message about the action, which might include other parameters. So the message about what's being hidden and the intended protection of that option could have slightly different interpretations. I'd like to hear if anyone has intended for the actual log action to be deleted / suppressed. If not, I'm happy to revert the recent patch, and we'll just update the wording in the deletion UI to be more clear about what is being removed. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [BREAKING CHANGE] Upcoming jQuery upgrade: Removing jQuery Migrate
Hey all, On 3 Jun 2014, Krinkle wrote: TL;DR: * We did not make the breaking change last week for Wikimedia; it is postponed. * MediaWiki 1.24.0 will ship with jQuery Migrate switched off. * Wikimedia non-Wikimedia wikis can enable jQuery Migrate if needed. * When MediaWiki 1.24 is released, we will switch off jQuery Migrate for Wikimedia wikis. This is now due. [0] The change [1] will land in master after the branch cut next week. It will roll out in 1.25wmf12, which will be deployed to Wikimedia wikis starting Wednesday 10 December: [1] * It will affect mediawiki.org and test wikis on Wednesday 10 December. * It will affect sister projects on Tuesday 16 December. * It will affect Wikipedias on Wednesday 17 December. For non-Wikimedia wikis, this will ship in MediaWiki 1.25.0. Thanks for all the help so far! Best, — Krinkle [0] https://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg76236.html [1] https://gerrit.wikimedia.org/r/#/c/137168/ [2] https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phabricator migration part II: Replacing gitblit with Diffusion
On 27 Nov 2014, at 20:02, Merlijn van Deen valhall...@arctus.nl wrote: On 26 November 2014 at 23:29, MZMcBride z...@mzmcbride.com wrote: If we're stuck with using callsigns, the idea of using the shortest possible strings (a four-character hash?) appeals to me. If particular repos want specific available hashes (, ), I'm fine with allocating on a first-come, first-served basis. I've fiddled a bit with this in the style of tail numbers / actual radio call signa: first letter is a category (country in a call sign), the rest is assigned as a number, unless someone wants a specific one. (..) https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsign_naming_conventions/Existing_repositories_valhallasw +1 as well. Like the restricted length. Not sure 4 is enough, but we can always grow later on. Most license plate systems do the same. Though I'm not sure that was for the best. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phabricator migration part II: Replacing gitblit with Diffusion
On Mon Dec 01 2014 at 8:28:50 PM Krinkle krinklem...@gmail.com wrote:
On 27 Nov 2014, at 20:02, Merlijn van Deen valhall...@arctus.nl wrote:
On 26 November 2014 at 23:29, MZMcBride z...@mzmcbride.com wrote:
If we're stuck with using callsigns, the idea of using the shortest
possible strings (a four-character hash?) appeals to me.
If
particular repos want specific available hashes (, ), I'm fine
with allocating on a first-come, first-served basis.
I've fiddled a bit with this in the style of tail numbers / actual
radio call signa: first letter is a category (country in a call sign),
the rest is assigned as a number, unless someone wants a specific one.
(..)
https://www.mediawiki.org/wiki/Phabricator/Diffusion/
Callsign_naming_conventions/Existing_repositories_valhallasw
+1 as well. Like the restricted length. Not sure 4 is enough, but we can
always grow later on.
/[A-Z]{4}/ produces 456976 possibilities. I don't think we'll
run out anytime soon :)
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Community Suggestions Regarding the Project
Hello! I am an OPW Intern for round#09 and will be working on a spelling dictionary project, the proposal of which is available here https://www.mediawiki.org/wiki/User:Ankitashukla/Proposal. Also, we'd be using this https://github.com/ankitashukla/spelling-dictionary-opw github repo for version controlling. Before we start off with the coding part, my mentors Kartik and Amir, and I thought it would be a great idea to have suggestions from everyone that might turnout to be very useful for us during the development of the project. We welcome all ideas of what your expectations are from the project, any specific design advice, any particular implementation or any advice, big or small, that might be useful to us. Thanks and regards, Ankita Shukla ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
