[MediaWiki-CodeReview] [MediaWiki r105870]: New comment added

[MediaWiki Mail]

"Fomafix" posted a comment on MediaWiki.r105870.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105870#c32772

Commit summary for MediaWiki.r105870:

Followup to r105854. Made directionality inline rather than block-level, 
because text alignment should be consistent with the rest of the site. Added 
support for Monobook and Modern skins.

Fomafix's comment:

The line wrap in Vector.php line 139 generates a trailing space in the 
clipboard when selecting the whole line with triple click in title. The other 
skins doesn't have this problem because they haven't a line wrap.

Examples:
* http://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia?useskin=vector → 
“Wikipedia:Fragen zur Wikipedia ”
* http://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia?useskin=monobook 
→ “Wikipedia:Fragen zur Wikipedia”

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Lua: parser interface

[Platonides]

Is it possible to hook Lua function calls? If so, I'd make a template
expansion a "call" to a function with that name.
That was the interface I envisioned when thinking how I'd do it if
making the language from scratch to suit wikitext
(I drafted some code, but didn't reach to a barely mature level).




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Lua: parser interface

[Victor Vasiliev]

On Wed, May 2, 2012 at 2:28 PM, Platonides  wrote:
> Is it possible to hook Lua function calls? If so, I'd make a template
> expansion a "call" to a function with that name.
> That was the interface I envisioned when thinking how I'd do it if
> making the language from scratch to suit wikitext
> (I drafted some code, but didn't reach to a barely mature level).

Do you mean a situation when you have template X and call to function
X is a transclusion of template X? I have also thought about that as
well. Not all titles are legitimate Lua function names, but there are
more serious issues with that.

This is close to how the first implementation of InlineScripts was
done in 2009. As it turned out, this approach has numerous
disadvantages, the main of which are performance issues (introducing
overhauls by calling the functions through parser instead of direct
call; this is actually a big problem when you have many function
calls), inability to return non-string data (like arrays) and
impossibility of exporting multiple functions from one template.
That's why I strongly believe that all code should be in modules and
modules should be interacting only through Lua itself.

—Victor

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] Release of educational videos under creative commons

[emijrp]

Another example of a recent video donation
https://commons.wikimedia.org/wiki/Category:Files_from_the_Australian_Broadcasting_Corporation

2012/4/25 emijrp 

> 2012/4/24 Samuel Klein 
>
>> Where's the latest thread on the Timed Media Handler progress?
>>
>> I am meeting with MIT Open CourseWare tomorrow - they want to expand
>> the set of videos they released last year under CC-SA, starting with
>> categories / vids that would be fill gaps on Wikipedia.  Any thoughts
>> on how to make that collaboration more effective would be welcome.
>>
>> SJ
>>
>>
> You can upload them to Internet Archive, if Wikipedia has temporal issues
> with videos. When the problems are fixed, we can move them from Internet
> Archive to Wikimedia Commons.
>
> --
> Emilio J. Rodríguez-Posada. E-mail: emijrp AT gmail DOT com
> Pre-doctoral student at the University of Cádiz (Spain)
> Projects: AVBOT  | 
> StatMediaWiki
> | WikiEvidens  | 
> WikiPapers
> | WikiTeam 
> Personal website: https://sites.google.com/site/emijrp/
>
>


-- 
Emilio J. Rodríguez-Posada. E-mail: emijrp AT gmail DOT com
Pre-doctoral student at the University of Cádiz (Spain)
Projects: AVBOT  |
StatMediaWiki
| WikiEvidens  |
WikiPapers
| WikiTeam 
Personal website: https://sites.google.com/site/emijrp/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r105870]: New comment added

[MediaWiki Mail]

"Amire80" posted a comment on MediaWiki.r105870.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105870#c32773

Commit summary for MediaWiki.r105870:

Followup to r105854. Made directionality inline rather than block-level, 
because text alignment should be consistent with the rest of the site. Added 
support for Monobook and Modern skins.

Amire80's comment:

Thanks for the comment. Should be addressed at 
https://gerrit.wikimedia.org/r/#change,6382 .

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Lua: parser interface

[Gabriel Wicke]

On 05/02/2012 04:01 AM, Tim Starling wrote:
> How about frame.args.name as an abbreviation for
> frame:getArgument('name'):expandTo( 'text/x-mediawiki' ) ?

Yep, that looks good to me. Maybe the specialized wikitext argument
variant could be called 'wikitextArgs' so that the general variant can
be used for ParserValues instead of the getArgument method?

> And how about frame.plainArgs.name as an abbreviation for
> frame:getArgument('name'):expandTo( 'text/plain' ) ?

Adding more xxxArgs methods does not seem to scale that well, and would
introduce a lot of extra method names to remember. It would also
encourage users to pick one representation when they would not need to
care about it, especially if they just pass through some content.

> I know you're not really asking for a review of Parsoid and its
> interfaces, but I worry as to whether your use of text/plain to
> indicate wikitext with comments stripped is appropriate.

I am not that happy with the text/plain bit too. text/x-mediawiki with a
separate progress or 'processing stage' component might be better, as it
would not conflate processing stage with the format. I am using a
numerical 'rank' value to track progress internally in Parsoid, but a
string would likely be user-friendlier for an external API like this.
There is an example for this further down in this post.

> If I were to provide Lua with a richer interface to PPFrame::expand(),
> I would be inclined to support at least some of those flags via named
> options, rather than rolling them up into a single string parameter.
> So instead of expandTo( 'text/plain' ) we might have:
> 
> frame:getArgument('name'):expand{
>expand_args = false,
>expand_templates = false,
>respect_noinclude = false,
>strip_comments = true }
> 
> Or, if forwards-compatibility requires that we don't support so many
> orthogonal options, some of the options could be rolled in together.
> The preceding could perhaps be written as:
> 
> frame:getArgument('name'):expand{ plain = true }
> 
> That doesn't preclude the use of overrides:
> 
> frame:getArgument('name'):expand{
>plain = true,
>strip_comments = false }
> 
> But it does seem like a can of worms. 

Some grepping through core and extension code left me with the
impression that there are relatively few common sets of flags used. As
an example, NO_ARGS and NO_TEMPLATES always seem to be used as a pair in
situations where just comment and noinclude (and company) handling is
needed.

If there remain use cases for fully orthogonal flags, then those could
still be supported with optional (named) argument of course, as you note.

> How about providing
> getArgument(), which will return an opaque ParserValue object with a
> single method called expand(). This method would theoretically take
> named parameters, but currently, none are defined. With no parameters,
> it provides some kind of reasonable template-expanding behaviour. Then
> frame.args would provide an abbreviated syntax for expand() with no
> parameters.

Yes, this looks very good to me. ParseValue with a heavily defaulted
expand() method should be a good compromise between convenience for the
currently common case without compromising the ability to work with
other content types, or specify the processing stage through a name or
flags. So the 'plain' example could look somewhat like this:

  arg:expand( format = 'tokens/x-mediawiki',
  phase = '0.1_noComments' ) --- named processing phase

>> The conversion of wikitext or other formats to an opaque value object
>> could be achieved using an object constructor:
>>
>>   --- 'value text' is parsed lazily
>>   ParserValue( 'text/x-mediawiki', 'value text', frame )
>>
>> The frame might be the passed-in parent frame, or a custom one
>> constructed with args assembled from other ParserValues.
> 
> Yes, this is an interesting idea. But I think I would prefer the
> factory to be a frame method rather than a global function. 

I'd be happy with that too. Custom child frames could still be created
using a frame:newChild method.

> Also,
> again, I am skeptical about the value of using a MIME type. How about
> an interface allowing either:
> 
> frame:newParserValue( 'value text' )
> 
> or named arguments:
> 
> frame:newParserValue{
>text = 'value text',
>fruitiness = 'high',
> }

+1, but I think some way to indicate the type and processing state of
the passed-in value will be needed if non-wikitext values are to be
supported. Further processing of a ParserValue depends on this
knowledge. Optional (named) arguments could be employed for this too:

  frame:newParserValue{
  type = 'tokens/x-mediawiki',
  value = { { type = 'tag',
  name = 'a',
  attribs = { href = 'http://foo' }
},
"Some link text",
{ type = 'endtag', name = 'a' }
  }
  }

Defaulting to wikitext and fully-preprocessed text for the processing
phase would be fine wi

[MediaWiki-CodeReview] [MediaWiki r105870]: New comment added

[MediaWiki Mail]

"Fomafix" posted a comment on MediaWiki.r105870.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/105870#c32774

Commit summary for MediaWiki.r105870:

Followup to r105854. Made directionality inline rather than block-level, 
because text alignment should be consistent with the rest of the site. Added 
support for Monobook and Modern skins.

Fomafix's comment:

Tracked as [[bugzilla:36409|Bug 36409]].

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[Wikitech-l] MediaWiki 1.19.0 released

[Sam Reed]

I'm happy to announce the availability of the first stable release
of the new MediaWiki 1.19 release series.

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

Frequently asked questions about upgrading:
http://www.mediawiki.org/wiki/Manual:FAQ#Upgrading

**
Download:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0.tar.gz

GPG signatures:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0.tar.gz.sig

Public keys:
https://secure.wikimedia.org/keys.html


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [Wikimedia r1723]: Revision status changed

[MediaWiki Mail]

"Jpostlethwaite" changed the status of Wikimedia.r1723 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1723

Old status:  new
New status: ok

Commit summary for Wikimedia.r1723:

MFT r1504, r1506, r1632, r1633, r1634, r1635, r1636, r1637, r1638, r1639, 
r1640, r1641, r1642, r1643, r1644, r1645, r1646, r1652, r1653, r1654, r1655, 
r1656, r1657, r1658, r1659, r1660, r1662, r1663, r1665, r1666, r1669, r1670, 
r1675, r1677, r1679, r1680, r1681, r1682, r1694, r1695, r1696, r1697, r1704, 
r1705, r1707, r1708, r1709, r1710, r1711, r1712, r1713, r1714, r1718, r1719, 
r1720

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [Wikimedia r1635]: New comment added

[MediaWiki Mail]

"Jpostlethwaite" posted a comment on Wikimedia.r1635.
URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1635#c32775

Commit summary for Wikimedia.r1635:

Updating documentation. See r1634.

Jpostlethwaite's comment:

No custom status codes will be added at this time.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [Wikimedia r1570]: New comment added

[MediaWiki Mail]

"Jpostlethwaite" posted a comment on Wikimedia.r1570.
URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1570#c32776

Commit summary for Wikimedia.r1570:

Failed payments should be marked with a failed status.

Jpostlethwaite's comment:

This is done in r1652.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [Wikimedia r1725]: Revision status changed

[MediaWiki Mail]

"Pgehres (WMF)" changed the status of Wikimedia.r1725 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1725

Old status:  new
New status: ok

Commit summary for Wikimedia.r1725:

Adding the payment instrument "Cash" back in for... cash we received, but lack 
more precise information about.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[Wikitech-l] Wikidata: ContentHandler code ready for review

[Daniel Kinzler]

Hi all

The first installment of the ContentHandler facility we need for Wikidata is now
on Gerrit, awyiting review:

https://gerrit.wikimedia.org/r/#change,6101

I already got a lot of useful input from several developers, and tried to
address them as well as I could. However, I would appreciate any additional
comments, so we can go ahead with this soon.

Please note that as it is, this changeset doesn't implement any new
functionality. Once it is merged in, I will submit changes to Article, EditPage,
DiffereEngine, etc. that make use of the new features introduced by the
ContentHandler facility. If you want a sneak preview, have a look at the
Wikidata branch of core:

https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/WikidataClient.git;a=tree

cheers
daniel

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [pywikipedia r10089]: New comment added

[MediaWiki Mail]

"Valhallasw" posted a comment on pywikipedia.r10089.
URL: http://www.mediawiki.org/wiki/Special:Code/pywikipedia/10089#c32777

Commit summary for pywikipedia.r10089:

Enable ignore list for repeated runs + some error handling.

Valhallasw's comment:

There is also a pagegenerators.FilteredGenerator method (pagegenerators.py:602) 
which wraps TextfilePageGenerator(). TextfilePageGenerator returns a list of 
pages which the FilteredGenerator uses to filter pages from another generator.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r115113]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r115113 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/115113

Old status:  new
New status: ok

Commit summary for MediaWiki.r115113:

Throw exceptions instead of dying, so they can be caught.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r115114]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r115114 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/115114

Old status:  new
New status: ok

Commit summary for MediaWiki.r115114:

Updated activeMWVersions to handle * for extended version numbers.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114996]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114996 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114996

Old status:  new
New status: ok

Commit summary for MediaWiki.r114996:

Added mwscriptwikiset-quite, based on mwscriptwikiset-short on /home.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r114997]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r114997 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114997

Old status:  new
New status: ok

Commit summary for MediaWiki.r114997:

Simplified mwscriptwikiset-quite to use mwscript.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r115091]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r115091 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/115091

Old status:  new
New status: ok

Commit summary for MediaWiki.r115091:

Added "all wikis have a version" sanity check to CDB building script.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r115092]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r115092 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/115092

Old status:  new
New status: ok

Commit summary for MediaWiki.r115092:

Fixed old c/p error in message.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r115093]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r115093 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/115093

Old status:  new
New status: ok

Commit summary for MediaWiki.r115093:

Actually treat "*" as "no extended version number".

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r115106]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r115106 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/115106

Old status:  new
New status: ok

Commit summary for MediaWiki.r115106:

Updated version directory regex.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r115107]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r115107 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/115107

Old status:  new
New status: ok

Commit summary for MediaWiki.r115107:

Tweaked sanity check error message.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r115108]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r115108 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/115108

Old status:  new
New status: ok

Commit summary for MediaWiki.r115108:

Add newlines as needed.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r115109]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r115109 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/115109

Old status:  new
New status: ok

Commit summary for MediaWiki.r115109:

Trim wikiversion comments to tidy things up a bit.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r115110]: Revision status changed

[MediaWiki Mail]

"Catrope" changed the status of MediaWiki.r115110 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/115110

Old status:  new
New status: ok

Commit summary for MediaWiki.r115110:

Output number of wikis in dblist file.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[Wikitech-l] Welcome Danielle Benoit, making engineering tutorials

[Sumana Harihareswara]

It is my pleasure to announce new Wikimedia Foundation contractor
Danielle Benoit, who will be working in the Engineering Community Team
on engineering tutorial materials for the next several weeks.

Danielle comes to us from previous roles in organizational culture
management, quality assurance, event management, and curriculum
development and teaching.  She's going to work with WMFers and with
other community members to create the tutorial materials for:

Using Git and Gerrit
Beginning Lua scripting and adapting templates to Lua
Optimizing your code's MySQL performance
Writing secure code and reviewing code for security
Adapting your Gadget to ResourceLoader and Gadgets 2.0

Foundation engineers will teach these tutorials at the Berlin hackathon
 in June, so
Danielle will help them prep, and improve written resources on
mediawiki.org to serve our whole engineering community.  (I'm also
working to get the Berlin tutorials videorecorded but it's not a sure
thing yet.)

Welcome!  (cc'd)

-- 
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Proposal: Special:SiteChanges for automatic deployment info

[Erik Moeller]

In the Wikimedia wikis, right now, we succeed to a varied degree at
letting communities know about deployments that affect them. We're
definitely getting better, and the 1.20wmf1 page is an example of
release notes done well:

http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf1
http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf1/overview

A concise summary with translations in multiple languages, followed by
a detailed list compiled from manually collected and curated commit
summaries. Nifty. And so much work that it's unlikely to be
sustainable. Indeed with wmf2 we're already taking shortcuts:

http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf2

No translations, no overview, less curation. And let's keep in mind
that this covers only the "regular two week cycle" deployment -- major
changes deployed between cycles aren't covered in either of those
summaries.

So how can we do better? I'd posit that it should be impossible to
deploy code without leaving an exposed audit trail generated from
commit messages, which can in turn be expanded by any interested
volunteer into a human-readable and translated summary.

I'd suggest exposing this information to a special page directly in
the relevant wiki, say "Special:SiteChanges". This special page would
show an automatically generated summary like so:


== Wednesday May 2, 19:03 ==
(2 hours ago)

'''[[mw:WMF deployments/345|Write or translate a deployment summary]]'''

Deployment 345 completed. The following changes are now running on this wiki.

=== In core ===

* ca7eb5c - Removed intval for undelete reason in API - ''committed by
Petr Onderka''
* 5813680 - Few documentation/type hint updates - ''committed by Reedy''
* e22a369 - Prevent sidebar links from jumping on page load -
''committed by Trevor Parscal'
...

=== In extension FlaggedRevs ===

* ce146dc - Fixing up LSB related stuff.. Some code duplication, but
meh for the moment (yay for us using static classes for hooks)

=== In extension DynamicPageList ===

..

== Tuesday, May 1, 15:01 ==
(1 day ago)

...


I leave it up to your imagination whether the summary would be
generated from the git repo the wiki resides in (in combination with a
deployment log), or pulled from MediaWiki.org,  some combination
thereof, or some other implementation strategy. Suffice it to say that
we'd ideally want to:

* Ensure that the process of recording this information is an
automated part of deploying code updates
* Filter extensions from the Special:SiteChanges summary that are not
actually activated
* Notice when new extensions are activated that were not active in a
previous state
* Enable anyone to write deployment summaries on MediaWiki.org
* Enable anyone to translate those summaries
* Load an existing summary in the correct language on Special:SiteChanges

In the magical database backed configuration future,
Special:SiteChanges might also be able to list out config changes, but
that seems far fetched right now

In the equally magical "notifications for everything" future, users
would be able to opt into getting notified whenever a deployment
occurs.

But keeping it at a base level of functionality, does this seem like a
feasible and desirable change? Like I said, I worry about our ability
to keep up without automating this whole process, so IMO it would be
good to incrementally start building out this functionality. Otherwise
we're constantly fighting an uphill battle to ensure information gets
disseminated in a consistent fashion. But it's possible I'm
overlooking major issues that would make this too difficult to be
worthwhile.

All best,
Erik

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal: Special:SiteChanges for automatic deployment info

[Tomasz Finc]

As part of the pre flight steps the mobile team generates a list of
gerrit changes that have gone into the deployment branch. We then
throw it on a wiki page so that its much easier to trace back what
changed. Our current list is here

http://www.mediawiki.org/wiki/Extension:MobileFrontend/Deployments

Formatting aside its become really useful to know exactly what's going
out without having to hound each developer about their changes.

This combined with Special:SiteChanges would be great in the glorious future.

--tomasz

On Wed, May 2, 2012 at 8:04 PM, Erik Moeller  wrote:
> In the Wikimedia wikis, right now, we succeed to a varied degree at
> letting communities know about deployments that affect them. We're
> definitely getting better, and the 1.20wmf1 page is an example of
> release notes done well:
>
> http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf1
> http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf1/overview
>
> A concise summary with translations in multiple languages, followed by
> a detailed list compiled from manually collected and curated commit
> summaries. Nifty. And so much work that it's unlikely to be
> sustainable. Indeed with wmf2 we're already taking shortcuts:
>
> http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf2
>
> No translations, no overview, less curation. And let's keep in mind
> that this covers only the "regular two week cycle" deployment -- major
> changes deployed between cycles aren't covered in either of those
> summaries.
>
> So how can we do better? I'd posit that it should be impossible to
> deploy code without leaving an exposed audit trail generated from
> commit messages, which can in turn be expanded by any interested
> volunteer into a human-readable and translated summary.
>
> I'd suggest exposing this information to a special page directly in
> the relevant wiki, say "Special:SiteChanges". This special page would
> show an automatically generated summary like so:
>
> 
> == Wednesday May 2, 19:03 ==
> (2 hours ago)
>
> '''[[mw:WMF deployments/345|Write or translate a deployment summary]]'''
>
> Deployment 345 completed. The following changes are now running on this wiki.
>
> === In core ===
>
> * ca7eb5c - Removed intval for undelete reason in API - ''committed by
> Petr Onderka''
> * 5813680 - Few documentation/type hint updates - ''committed by Reedy''
> * e22a369 - Prevent sidebar links from jumping on page load -
> ''committed by Trevor Parscal'
> ...
>
> === In extension FlaggedRevs ===
>
> * ce146dc - Fixing up LSB related stuff.. Some code duplication, but
> meh for the moment (yay for us using static classes for hooks)
>
> === In extension DynamicPageList ===
>
> ..
>
> == Tuesday, May 1, 15:01 ==
> (1 day ago)
>
> ...
> 
>
> I leave it up to your imagination whether the summary would be
> generated from the git repo the wiki resides in (in combination with a
> deployment log), or pulled from MediaWiki.org,  some combination
> thereof, or some other implementation strategy. Suffice it to say that
> we'd ideally want to:
>
> * Ensure that the process of recording this information is an
> automated part of deploying code updates
> * Filter extensions from the Special:SiteChanges summary that are not
> actually activated
> * Notice when new extensions are activated that were not active in a
> previous state
> * Enable anyone to write deployment summaries on MediaWiki.org
> * Enable anyone to translate those summaries
> * Load an existing summary in the correct language on Special:SiteChanges
>
> In the magical database backed configuration future,
> Special:SiteChanges might also be able to list out config changes, but
> that seems far fetched right now
>
> In the equally magical "notifications for everything" future, users
> would be able to opt into getting notified whenever a deployment
> occurs.
>
> But keeping it at a base level of functionality, does this seem like a
> feasible and desirable change? Like I said, I worry about our ability
> to keep up without automating this whole process, so IMO it would be
> good to incrementally start building out this functionality. Otherwise
> we're constantly fighting an uphill battle to ensure information gets
> disseminated in a consistent fashion. But it's possible I'm
> overlooking major issues that would make this too difficult to be
> worthwhile.
>
> All best,
> Erik
>
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] BugZilla Portal (NEW)

[Krinkle]

Hey all,

Now that we're on a more regular deployment schedule, staying on top of the
blocking bugs and deviding lists into smaller, more managable chunks, is more
and more important.

For that reason I put together a quick tool:

https://toolserver.org/~krinkle/wmfBugZillaPortal/

It is already becoming clear that there is a lot of stuff left behind from past
versions. We should probably start moving stuff to later verisons and keep an
eye on it more regularly.

-- Krinkle


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Informal English lessons for Wikimedia developers - May 5 or 6

[Andrew Garrett]

I'm also happy to help out, if Erika does want a hand.

On Sun, Apr 29, 2012 at 8:16 AM, Sumana Harihareswara  wrote:

> Samat - yes, I know this would be useful for a lot of people, but since
> this particular volunteer only has a limited amount of time and wants to
> learn more about software development, I'm choosing to ask her to
> specifically help our developer community.  You can email Erika (cc'd)
> to let her know which sessions you could attend.
>
> --
> Sumana Harihareswara
> Engineering Community Manager
> Wikimedia Foundation
>
>
> On 04/28/2012 06:11 PM, Samat wrote:
> > This initiative would be helpful not just for developers (and thanks for
> > this possibility Erika, Sumana in the name of developers).
> > I would surely participate in a similar lesson...
> >
> > Samat
> >
> >
> > On Sun, Apr 29, 2012 at 00:00, Sumana Harihareswara
> > wrote:
> >
> >> Some Wikimedia developers have requested help improving their English
> >> writing skills.  Erika Hanson is volunteering her proofreading skills to
> >> help by leading interactive proofreading sessions -- we ran a pilot
> >> today and it was successful enough that we'll do another one next
> weekend.
> >>
> >> Participants paste what they've written into the Etherpad
> >> http://notes.wikimediadc.org/p/english-lessons by Thursday night, so
> >> Erika has time to read it and mark problem areas in boldface.  Then,
> >> during the tutorial session, Erika gives the learner lessons in
> >> spelling, grammar, punctuation, etc., for about 15 minutes per student.
> >>  If she has time in the 15 min., she'll then move on to matters of
> >> style.  Discussion can be within the Etherpad chat.
> >>
> >> If you want to participate, email Erika (cc'd) with the date/times that
> >> you can attend (your 2 choices are below - I don't know whether Erika
> >> can do both times or just the more popular 1), and put something you've
> >> written into the Etherpad by the end of Thursday.  It should be at least
> >> 200 words long -- blog entry, email, school essay, whatever.
> >>
> >>
> >> ALBUQUERQUE, 1:30pm-3:30pm , Sat, May 5 2012
> >> UTC, 19:30-21:30 Sat, May 5 2012
> >> AMSTERDAM, 21:30-23:30 Sat, May 5 2012
> >> MUMBAI, 1am-3am Sun, May 6 2012
> >>
> >> or
> >>
> >> ALBUQUERQUE, 10am-noon, Sun, May 6 2012
> >> MUMBAI, 9:30pm-11:30pm, Sun, May 6 2012
> >> UTC, 16:00-18:00, Sun, May 6 2012
> >> AMSTERDAM, 18:00-20:00, Sun, May 6 2012
> >>
> >> If people learn effectively from this, then we could repeat it.
> >>
> >> --
> >> Sumana Harihareswara
> >> Engineering Community Manager
> >> Wikimedia Foundation
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Andrew Garrett
Wikimedia Foundation
agarr...@wikimedia.org
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] BugZilla Portal (NEW)

[Krinkle]

On May 3, 2012, at 5:28 AM, Krinkle wrote:

> Hey all,
> 
> Now that we're on a more regular deployment schedule, staying on top of the
> blocking bugs and deviding lists into smaller, more managable chunks, is more
> and more important.
> 
> For that reason I put together a quick tool:
> 
> https://toolserver.org/~krinkle/wmfBugZillaPortal/
> 
> It is already becoming clear that there is a lot of stuff left behind from 
> past
> versions. We should probably start moving stuff to later verisons and keep an
> eye on it more regularly.
> 
> -- Krinkle
> 

This tool (among others) is in source control and running on toolserver from 
trunk:

* https://svn.toolserver.org/svnroot/krinkle/trunk/wmfBugZillaPortal/
* https://fisheye.toolserver.org/browse/krinkle/trunk/wmfBugZillaPortal

-- Krinkle

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] BugZilla Portal (NEW)

[Rob Lanphier]

On Wed, May 2, 2012 at 8:28 PM, Krinkle  wrote:
> https://toolserver.org/~krinkle/wmfBugZillaPortal/

Oooo, nice, thanks for this Krinkle!

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Full support for djvu files

[Alex Brollo]

Djvu files are the wikisource standard supporting proofreading. They have
very interesting features, being fully "open" in structure and layering,
and allowing a fast and effective sharing into the web, when they are
stored in their "indirect" mode. Most interesting, their text layer - which
can be easily extracted - contains both the mapped text from OCR and
metadata. A free library - divuLibre - allows full command line access to
any file content.

Presently, djvu files structure and features are minimally used. Indirect
mode is IMHO not supported at all, there's no mean to access to mapped text
layer nor to metadata, and only the "full text" can be accessed once, when
creating a new page into Page namespace.

It would be great IMHO:
* to support indirect mode as the standard;
* to allow free, easy access to the full text layer content from wikisource
user interface.

Alex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l