Wikitech-l May 2013

wikitech-l@lists.wikimedia.org

158 participants
192 discussions

Backporting Reference
by Greg Grossmeier 16 May '13

16 May '13

Hello all, I just wanted to send a note about a reference doc on the MediaWiki wiki on backporting bug fixes: https://www.mediawiki.org/wiki/Backporting_Fixes It addresses the difference between backports to stable releases versus the code on the WMF cluster (as well as the special process for security related bugs). Of note: We now have backport "flags" in bugzilla to track the backport process. There is one for stable releases ("Backport_to_Stable") and one for the WMF cluster ("Backport_WMF"). I hope this can help to clarify some confusion around the backporting process. Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

VisualEditor - Paste Displayed Text UI
by Jiabao Wu 16 May '13

16 May '13

Hi I am trying to fix bug 48489 - Can not paste new link anchor for VisualEditor. https://bugzilla.wikimedia.org/show_bug.cgi?id=48489 I have been able to add the functionality to the link inspector to edit the displayed text. https://gerrit.wikimedia.org/r/#/c/64055/ I have not worked on the appearance of the interface. What user interface the community would like to get? Which existing widgets if any should be included when adding this functionality? (currently just using InputWidget.js) Cheers, Jiabao

2 1

[Extension:Score] Unable to create a single score from multiple pages
by David Cuenca 16 May '13

16 May '13

Hi, At ca-ws we have started creating musical scores and we have found out that when transcluding two pages into one, it is only possible to generate two independent audio files instead of one with the whole score. Example with two pages http://ca.wikisource.org/wiki/P%C3%A0gina%3A30_can%C3%A7ons_populars_catala… http://ca.wikisource.org/wiki/P%C3%A0gina%3A30_can%C3%A7ons_populars_catala… Transcluded score: http://ca.wikisource.org/wiki/Els_micalets_d%27Espanya Is there any way to combine multiple pages into a single file? I have tried to transclude each section independently, but I always get a wall of text with errors. Also interesting would be to give the user the option to save that lilypond file. Cheers, David --Micru

1 1

Announcing the Flow Portal(s)
by Brandon Harris 16 May '13

16 May '13

Hello! As many of you know, the Wikimedia Foundation is now actively engaged in designing a next-generation discussion and workflow system called Flow, initially slated to replace user talk pages. Flow is an ambitious project (on par with the VisualEditor) and will touch nearly every aspect of the Wikimedia experience. We need ''your'' help and input. We have started a portal for information and discussion. You can find it on the English Wikipedia here: http://en.wikipedia.org/wiki/Wikipedia:Flow And on MediaWiki here: http://www.mediawiki.org/wiki/Flow_Portal (We'll be creating one on meta as well). At the Flow portal, you can read about what we're doing and why, as well as play around with an interactive prototype. We're desperately interested in your feedback and thoughts. There are things that we know, and things that we know that we don't know. But there are also things that we *don't* know that we don't know. And we want to reduce that lack of knowledge. We will also be conducting additional office hours for a variety of timezones - as many as we need to - and will also be open to having conversations via Google hangouts and/or Skype as need be. I am always around on irc (freenode, username "jorm") and am willing to answer any questions you may have. -b. --- Brandon Harris, Senior Designer, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

2 1

MediaWiki 1.21 release delayed until May 18
by Mark A. Hershberger 16 May '13

16 May '13

Despite the my intention to release 1.21 today, I have to delay it until May 18. Yesterday someone pointed out a blocker to me. While we have a work-around for this, I don't have time to integrate it right now, so the release needs to be delayed until Saturday. On 05/13/2013 03:12 PM, Mark A. Hershberger wrote: > The final release candidate for MediaWiki 1.21 (rc5) is available for > download. See the end of this email for details. There are a number of > bug fixes in this release that were not in rc4. Please test this > version and report any problems. Barring any show-stoppers, the final > release will be on May 15 will be the same as this with just a change to > the version number and updated release notes. > > Changes since rc4: > > * Changes to JS/JSON value encoding were backed out. > * API: Fix parameter validation in setnotificationtimestamp > commit 18eb39ecb5b89518c3d4a6cc79834a2c121477ff > Author: Brad Jorsch <bjorsch(a)wikimedia.org> > Date: Fri Mar 15 14:03:19 2013 -0400 > > * (bug 47271) $wgContentHandlerUseDB should be set to false during the > upgrade > * (bug 47489) Installer now automatically selects the next-best database > type if > the PHP mysql extension is not loaded, preventing fatal errors in some > cases. > * (bug 47202) wikibits: FF2Fixes.css should not be loaded in Firefox 20. > * (bug 46590) 'AbortChangePassword' hook added/documented (find bug) > * (bug 46848) toggleLinkPremade added linksPassthru > * (bug 47950) Fix IndexPager detection of "is first" state > * (bug 47304) added safeXmlEncodings to UploadBase for svg uploads > * (bug 46608) CoreParserFunctions::anchorencode should return a string > > > * Full release notes: > https://www.mediawiki.org/wiki/Release_notes/1.21 > > > ********************************************************************** > Download: > http://download.wikimedia.org/mediawiki/1.21/mediawiki-core-1.21.0rc5.tar.gz > http://download.wikimedia.org/mediawiki/1.21/mediawiki-1.21.0rc5.tar.gz > > Patch to previous version (1.20.0), without interface text: > http://download.wikimedia.org/mediawiki/1.21/mediawiki-1.21.0rc5.patch.gz > Interface text changes: > http://download.wikimedia.org/mediawiki/1.21/mediawiki-i18n-1.21.0rc5.patch… > > GPG signatures: > http://download.wikimedia.org/mediawiki/1.21/mediawiki-core-1.21.0rc5.tar.g… > http://download.wikimedia.org/mediawiki/1.21/mediawiki-1.21.0rc5.tar.gz.sig > http://download.wikimedia.org/mediawiki/1.21/mediawiki-1.21.0rc5.patch.gz.s… > http://download.wikimedia.org/mediawiki/1.21/mediawiki-i18n-1.21.0rc5.patch… > > Public keys: > https://secure.wikimedia.org/keys.html > > > _______________________________________________ > MediaWiki-distributors mailing list > MediaWiki-distributors(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mediawiki-distributors >

2 2

Code style: overuse of Html::element()
by Max Semenik 15 May '13

15 May '13

Hi, I've seen recently a lot of code like this: $html = Html::openElement( 'div', array( 'class' => 'foo' ) . Html::rawElement( 'p', array(), Html::element( 'span', array( 'id' => $somePotentiallyUnsafeId ), $somePotentiallyUnsafeText ) ) . Html::closeElement( 'div' ); IMO, cruft like this makes things harder to read and adds additional performance overhead. It can be simplified to $html = '<div class="foo'><p>' . Html::rawElement( 'p', array(), Html::element( 'span', array( 'id' => $somePotentiallyUnsafeId ), $somePotentiallyUnsafeText ) ) . '</p></div>'; What's your opinion, guys and gals? -- Best regards, Max Semenik ([[User:MaxSem]])

15 21

Proposal: MediaWiki Group (((NAME)))
by Anton Bolfing 15 May '13

15 May '13

Hi, following the process for requesting the creation of a MediaWiki group, here is a proposal for MediaWiki Group Accessibility Tracking https://www.mediawiki.org/wiki/Groups/Proposals/Accessibility_Tracking Your endorsements, improvements and feedback are welcome at the wiki page. Thank you! PS: see also http://www.mediawiki.org/wiki/Groups/Proposals -- Anton Bolfing Dr., Leiter Forschung & Entwicklung Zugang für alle Schweizerische Stiftung zur behindertengerechten Technologienutzung Dörflistrasse 10 8057 Zürich Tel +41 (0)44 515 54 24 Email anton.bolfing(a)access-for-all.ch Web www.access-for-all.ch/ Blog www.access4all.ch/blog/ Twit http://twitter.com/access4all

1 0

Processing unknown named template parameters with Scribunto
by Toni Hermoso Pulido 15 May '13

15 May '13

Hello, yesterday I found myself with a problem similar to the one described here: http://stackoverflow.com/questions/15164710/mediawiki-templates-inherit-par… But, actually, I would like to process template paramaters without first having to return the values associated to them -> {{{param1}}}, {{{param2}}}. Let's say, something like processing argv, where argv may contain argv['param1'], argv['param2'], but not knowing whether param1 or param2 do exist first (I should iterate over keys in this case…) Is this something that might be done somehow by using Lula (Scribunto)? Thanks! -- Toni Hermoso Pulido http://www.cau.cat

3 4

One Week Deploy Cycle Recommendation
by Greg Grossmeier 14 May '13

14 May '13

https://wikitech.wikimedia.org/wiki/Deployments/One_week [tl;dr] My recommendation for us to switch to a one-week deploy is to use Robla's suggestion (Option B on the wiki page[0]) starting on Monday June 10th. This will coincide with the start of the MediaWiki 1.22wmf6 deployment on WMF servers. Unless there are any major concerns with this proposal, I'll start modifying the relevant parts of the wiki (mostly https://wikitech.wikimedia.org/wiki/Deployments and https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap#Schedule_for_the_depl… ). == Riding the Train == Now is the time to start getting more development teams to start riding the MW Core deploy train. If a one-week cycle/14 day lifespan (with the always possible important backports available) is something doable for your team right now, please do let me know. If it isn't, please let me know what would be "good enough". Would Option A have been? == Reasoning for Option B == Although we strive to be a continuous integration and deployment house, we aren't quite there yet. With that in mind, having the space between deploying to test/test2/mediawiki.org and the non-WP project sites is beneficial. Possible workarounds to this problem included having two deploy windows on Monday (in the Option A version); one for test/test2/mediawiki in the morning, with a few hours gap then one for all non-WP project sites. The gap would be used for both automated and manual tests. While the automated tests could be scheduled and completed in a reasonable time frame, counting on the QA team to complete manual tests and report bugs in a small window isn't a dependency we should have right now; manual tests still catch a lot of issues that the automated ones do not. Going with Option B does already reduce our wmfXX branch lifespan from 24 days to 14 days. "Lifespan" being the number of days that any branch is live on any wiki (from the day it goes to test/test2/mediawiki to the day its "slot" is replaced with a new wmfXX branch). Limiting our testing time to get down to 10 days doesn't seem worth it yet. == Future == To get us down to a quicker cycle (lifespan of 10 or fewer days) we'll need to do a bit more work on the QA/testing side of things (which involves everything from betalabs, to test/test2, to unit tests, to selenium, et al). We're on the right path, thankfully. Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

Proposal: Let's move to a one-week deploy cycle
by Greg Grossmeier 14 May '13

14 May '13

Hello all, Let's move our MediaWiki deploy cycle to weekly instead of 2-week. This will also reduce the number of standing deployment windows throughout the week by having those projects/teams simply "ride the MediaWiki train." == Current situation == Right now, a new version of MediaWiki is rolled out to the WMF cluster over a two-week period. You can see the general flow of how it works on this page describing the deploy schedule for the 1.22 release: https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap#Schedule_for_the_depl… == What are the drawbacks of two-weeks? == These are mostly known by everyone so I'll just simply state the most obvious one :-) It takes up to 2 weeks for new features/bug fixes to be rolled out to the various Wikimedia wikis. == What would a one-week cycle look like? == This has been talked about a bit, including during the last In Town Week for WMF Engineering in late-February. I've coalesced on one proposal at: https://wikitech.wikimedia.org/wiki/Deployments/One_week This seems like a reasonable approach to me. Please respond here or on the talk page with comments/suggestions/etc. == Major benefit/goal with one-week cycle == Our current list of deployment windows during the week is pretty large, and it is not uncommon for a week to practically fill up with bug fix windows. If we moved to a weekly cycle then more of those bug-fixes could just roll out with the normal MediaWiki deploy. == Goal Timeline? == I would love to get us switched over to a one-week cycle by mid-June. Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

15 24

← Newer
1
...
6
7
8
9
10
11
12
...
20
Older →

Jump to page:

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 May 2013