Wikitech-l April 2012

wikitech-l@lists.wikimedia.org

152 participants
188 discussions

Start a nNew thread

git reading tips
by Thomas Gries 29 Apr '12

29 Apr '12

I like that http://sitaramc.github.com/gcs/index.html and that http://sitaramc.github.com/concepts/detached-head.html

1 0

Git - I just want to pull the HEAD version
by Stephan Gambke 28 Apr '12

28 Apr '12

Ok, I don't get it. All the time I do a pull I get conflicts. Latest just now: CONFLICT (delete/modify): includes/api/ApiTokens.php deleted in HEAD and modified in 4cee7f1bb6f5b40134f211a626fd70504fc216dd. Version 4cee7f1bb6f5b40134f211a626fd70504fc216dd of includes/api/ApiTokens.php left in tree. Also the IDE I use (Netbeans) shows loads of local changes I never did. Can somebody please enlighten me on how to just pull the latest HEAD version, no questions asked?! Thanks, Stephan

3 6

Fwd: Cache hit rate changes - deliberate?
by Harry Burt 28 Apr '12

28 Apr '12

Hey all. Around the time of the 1.19 deployments back in February-time, there was some concern on this list about the downwards spike in the parser cache hit rate, as shown on [1]. There was, however, also evidence that it was returning to "normal" (previous) rates and so the concern dissipated. Contrary to expectation, however, we're now two months on and the new "normal" rates are still significantly below the old "normal" rates (or to put it another way, the miss rate is still considerably higher than it used to be). I confess this is an area I know little about, so I thought I'd just flag it up for review. Regards, Harry (User:Jarry1250) [1] http://bit.ly/JI41CR

1 0

22 new extensions in Git
by Chad 27 Apr '12

27 Apr '12

Hi everyone, I've migrated the 22 extensions that were on the queue today. I set permissions based on the requests--if anything needs adjusting, just let me know. -Chad

3 3

Commits IDs, change IDs, legacy change IDs, oh my!
by Erik Moeller 27 Apr '12

27 Apr '12

Hi all, can we agree on how we want to identify changes - when deploying code - when merging follow-ups - when commenting on bugzilla? Take a look at http://wikitech.wikimedia.org/view/Server_admin_log to see an example of a mix between Gerrit legacy change IDs (integers, as URLs) and commit IDs. For commit messages the recommendation is to use change IDs (as hashes). So this means constant back and forth between different ID types, which is confusing to developers and users. I'm personally not a fan of the Gerrit change-IDs in plain form, because I can't use them with commands like 'git log' or 'git show' without grepping through commit messages. They tie us pretty heavily to Gerrit as the gateway to all info as opposed to using Git's native lookup capabilities. One proposal: - Gerrit URLs for links on Bugzilla, links on wikis, follow-up to un-merged commits - Commit SHA-1s for deployment log entries and follow-ups to merged commits Rationale: - A Gerrit URL helps others skip past the fragile Gerrit search and go right to the relevant change. This gives them access to change-ID, SHA-1s, and anything else they may need. It's appropriate when you're likely to need to go into the full context of a change. - A SHA-1 gives you instant visibility to the code in your repo without having to use Gerrit as an intermediary, or having to do slow searches of your commit messages for a change-ID. Just do 'git show'. Git intelligently parses abbreviated hashes as well. It's appropriate when you're past the point of code review and are just referring to a change that's sitting somewhere in the repo. This is just one possible approach, and I'm sure this is something we can argue about endlessly. I don't much care what pattern we adopt, as long as it's reasonably consistent, especially for deployment log entries and follow-ups. Thanks, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

7 6

@param documentation
by Jeremy Postlethwaite 27 Apr '12

27 Apr '12

Hello! In the Mediawiki coding conventions section on PHP, the format for @param tag is not what Doxygen recommends. http://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP#Comments_and_Do… We have: General format for parameters is such: @param $varname [type]: [description]. Multiple types can be listed by separating with a pipe character. I added a note in the document: Doxygen documentation states that @param should have the same format as phpDocumentor[1]<http://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP#cite_note-0> : @param datatype1|datatype2 $paramname description How should we deal with this? Thanks. -- Jeremy Postlethwaite jpostlethwaite(a)wikimedia.org 415-839-6885 x6790 Backend Software Developer Wikimedia Foundation <http://wikimediafoundation.org/>

7 8

MediaWiki 1.19.0rc1
by Sam Reed 26 Apr '12

26 Apr '12

I'm happy to announce the availability of the first release candidate release of the new MediaWiki 1.19 release series. Please test it and let us know what you think of it. Barring new bug reports, this release candidate will soon be released as MediaWiki 1.19.0. Please try it out and let us know what you think. Don't run it on any wikis that you really care about, unless you are both very brave and very confident in your MediaWiki administration skills. MediaWiki 1.19 is a large release that contains many new features and bug fixes. This is a summary of the major changes of interest to users. You can consult the RELEASE-NOTES-1.19 file for the full list of changes in this version. Our thanks go to everyone who helped to improve MediaWiki by testing the beta release and submitting bug reports. **************************************************************** What's new? **************************************************************** MediaWiki 1.19 brings the usual host of various bugfixes and new features. Comprehensive list of what's new is in the release notes. * Bumped MySQL version requirement to 5.0.2. * Disable the partial HTML and MathML rendering options for Math, and render as PNG by default. * MathML mode was so incomplete most people thought it simply didn't work. * New skins/common/*.css files usable by skins instead of having to copy piles of generic styles from MonoBook or Vector's css. * The default user signature now contains a talk link in addition to the user link. * Searching blocked usernames in block log is now clearer. * Better timezone recognition in user preferences. * Extensions can now participate in the extraction of titles from URL paths. * The command-line installer supports various RDBMSes better. * The interwiki links table can now be accessed also when the interwiki cache is used (used in the API and the Interwiki extension). Internationalization - -------------------- * More gender support (for instance in user lists). * Add languages: Canadian English. * Language converter improved, e.g. it now works depending on the page content language. * Time and number-formatting magic words also now depend on the page content language. * Bidirectional support further improved after 1.18. Full release notes: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=RELEASE- NOTES-1.19;hb=REL1_19 https://www.mediawiki.org/wiki/Release_notes/1.19 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0rc1.tar.gz Patch to previous version (1.19.0beta2): http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0rc1.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0rc1.tar.gz.sig http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0rc1.patch.gz.si g Public keys: https://secure.wikimedia.org/keys.html

1 0

MediaWiki maintenance release 1.18.3
by Sam Reed 26 Apr '12

26 Apr '12

I would like to announce the release of MediaWiki 1.18.3. This release correct issues from the 1.18.2 security release, and also some other bugs. * (bug 35446) Using "{{nse:}}" with an invalid namespace name no longer throws a PHP warning. * (bug 35567) The whole password reminder e-mail is now sent in the same language. * (bug 35961) Hash comparison should always be strict. * (bug 35671) PHP Notice: Undefined index: gettoken in includes/api/ApiMain.php on line 598. * Fix broken email confirmation expiration caused by MWCryptRand changes. Full release notes: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=RELEASE- NOTES-1.18;hb=REL1_18 https://www.mediawiki.org/wiki/Release_notes/1.18 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.3.tar.gz Patch to previous version (1.18.2): http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.3.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.3.tar.gz.sig http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.3.patch.gz.sig Public keys: https://secure.wikimedia.org/keys.html

1 0

MediaWiki maintenance release 1.17.4
by Sam Reed 26 Apr '12

26 Apr '12

I would like to announce the release of MediaWiki 1.17.4. This release correct issues from the 1.17.3 security release, and also some other bugs. * (bug 35961) Hash comparison should always be strict. * Fix broken email confirmation expiration caused by MWCryptRand changes. * (bug 35671) PHP Notice: Undefined index: gettoken in includes/api/ApiMain.php on line 598. Full release notes: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=RELEASE- NOTES;hb=REL1_17 https://www.mediawiki.org/wiki/Release_notes/1.17 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.4.tar.gz Patch to previous version (1.17.3): http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.4.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.4.tar.gz.sig http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.4.patch.gz.sig Public keys: https://secure.wikimedia.org/keys.html

1 0

xsl wiki markup -> html
by sancelot＠free.fr 26 Apr '12

26 Apr '12

Hi, I would like to know if there already exists xsl stylesheets that are able to translate wiki markup to html or html to wiki markup. Regards S.Ancelot

2 1

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 April 2012