Re: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)

[Markus Glaser]

Hi Moriel,

I like that idea very much. In the use case I have in mind, though, I do have 
actual releases. Do you think it's possible for your extension to also consider 
tags? I am thinking of something like a tagging convention, e.g. "RELEASE 
v1.20". ExtensionStatus could then "parse" the tag and send it back to the user.

Best,
Markus
(mglaser)


-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Moriel 
Schottlender
Gesendet: Montag, 13. Mai 2013 06:27
An: wikitech-l@lists.wikimedia.org
Betreff: [Wikitech-l] New extension: Special:ExtensionStatus (opinions?)

Hello everyone,

I'd like to get your opinions and critique on my very first MediaWiki 
extension, which, I hope, will be helpful to other developers.

I noticed that there's no easy way of seeing if extensions that we have 
installed on our MediaWiki require update, and there are even some extensions 
that get so little regular attention that when they do get updated, there's no 
real way of knowing it (unless we check specifically).

It can be annoying when encountering problems or bugs, and then discovering 
that one of our extensions (probably the one we least expected) actually has an 
update that fixed this bug.

So, I thought to try and solve this issue with my extension. Since MediaWiki's 
changes are submitted through gerrit, I thought I'd take advantage of that and 
perform a remote check to see if there are any new commits that appeared in any 
of the extensions since they were installed.

How it works, briefly: the system compares the local repository date to the 
list of latest commits on gerrit's repo for the extension to see how many 
commits a user is behind on. If the user doesn't have a local git for the 
extension (or if they downloaded the extension manually) the system falls back 
to testing the local modification date for the files. It's not perfect, but it 
can give people a general idea of whether or not their extensions need some TLC.

The extension is available on GitHub:
https://github.com/mooeypoo/MediaWiki-ExtensionStatus along with screenshots 
and a short possible todo list.

There's a list of things I plan to try and improve, some of them are meant to 
make the lives of newbie developers (like me!) easier, but I'd love it if I 
could get feedback from you all and see if you think this could be helpful to 
you.
Would you like to see anything else in it? Do you think I'm in the right 
direction or am I doing it all wrong?

Be merciless!
Okay, maybe not *completely* merciless, but please don't hold back. This is my 
very first extension, and beyond wanting to make this a good extension, I also 
want to get a sense of whether or not I got into MW development right, and if 
there is anything I should have done (or be doing) differently.

Please let me know what you think!

Moriel
(mooeypoo)



--
No trees were harmed in the creation of this post.
But billions of electrons, photons, and electromagnetic waves were terribly 
inconvenienced during its transmission!
___
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] SMW Developer Workshop - when?

[Markus Glaser]

Hi Yury,

 

some time ago you proposed a SMW webinar for developers [1], which I find is a 
really great idea! But it seems no date has been set yet. As there are a number 
of interested participants, I think we’re ready to take this one step further J 
and find a time slot. Shall we use the talk page?

 

Best,

Markus

(mglaser)

 

[1] http://semantic-mediawiki.org/wiki/1st_SMW_webinar_for_developers

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

Re: [Wikitech-l] [MediaWiki-l] Announcement: Mark y Markus leading MediaWiki Release Management

[Markus Glaser]

Wjhonson,

you can find the log here:
http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20130620.txt

Cheers,
Markus

-Ursprüngliche Nachricht-
Von: mediawiki-l-boun...@lists.wikimedia.org 
[mailto:mediawiki-l-boun...@lists.wikimedia.org] Im Auftrag von Wjhonson
Gesendet: Freitag, 26. Juli 2013 18:57
An: mediawik...@lists.wikimedia.org
Cc: wikitech-l@lists.wikimedia.org; mediawiki-annou...@lists.wikimedia.org
Betreff: Re: [MediaWiki-l] Announcement: Mark y Markus leading MediaWiki 
Release Management

It would be helpful if someone could link to the IRC log of this
 

 

 

-Original Message-
From: Yury Katkov 
To: MediaWiki announcements and site admin list 

Cc: Wikimedia developers ; mediawiki-announce 

Sent: Fri, Jul 26, 2013 9:53 am
Subject: Re: [MediaWiki-l] Announcement: Mark y Markus leading MediaWiki 
Release Management


It's great that Wikimedia Foundation have started to care more about 3rd 
parties!
-
Yury Katkov, WikiVote



On Fri, Jul 26, 2013 at 7:41 PM, Greg Grossmeier  wrote:
> Full announcement on the blog:
> http://blog.wikimedia.org/2013/07/26/future-third-party-releases-media
> wiki/
>
>> Today, the Wikimedia Foundation is pleased to announce that we have 
>> contracted with two long-time members of the MediaWiki community–Mark 
>> Hershberger and Markus Glaser–to manage and drive forward third-party 
>> focused releases of MediaWiki.
>
>> Over a month ago, the Wikimedia Foundation sent out a request for 
>> proposals (RFP) to help us fill an important and underserved role in 
>> the development of MediaWiki. Two very solid proposals were produced, 
>> the community weighed in with questions and comments, and there was 
>> an open IRC office hour with the authors and interested community 
>> members. The Wikimedia Foundation is pleased with the outcome of this 
>> RFP and excited to begin this new chapter in the life of MediaWiki.
>
> Join me in congratulating Mark and Markus!
>
> Greg
>
> --
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
>
> ___
> MediaWiki-l mailing list
> mediawik...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

___
MediaWiki-l mailing list
mediawik...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l


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

[Wikitech-l] Selenium testing framework

[Markus Glaser]

Hi everybody,

at the Wkimedia Developers' Workshop, I introduced a Selenium testing framework 
for MediaWiki. Since it has now been promoted to maintenance/tests,  I have 
provided some initial information it on 
http://www.mediawiki.org/wiki/SeleniumFramework . I would be very happy about 
comments and ideas for further improvement. Also, if you intend to use the 
framework for your tests, please let me know. I will be happy to assist.

Regards,
Markus Glaser

__

Social Web Technologien
Leiter Softwareentwicklung
Hallo Welt! - Medienwerkstatt GmbH

__

Untere Bachgasse 15
93047 Regensburg

Tel.  +49 (0) 941 - 56 95 94 - 92

www.hallowelt.biz<http://www.hallowelt.biz/>
gla...@hallowelt.biz<mailto:gla...@hallowelt.biz>

Sitz: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer:
Anja Ebersbach, Markus Glaser,
Dr. Richard Heigl, Radovan Kubani

__

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

Re: [Wikitech-l] Selenium testing framework

[Markus Glaser]

Hi Dan,

will provide a working example with no need to include any extensions in the 
course of this week. In the meantime, you might want to make sure that 
$wgSeleniumTiffTestUploads = false;
in PagedTiffHandler_tests.php. Then, the test will not try to upload any of the 
pictures from libtiff. In order for the tests to succeed, you need to upload 
Multipage.tiff into the wiki. If there are any images missing, please let me 
know and I will send them to you. Actually, I didn't want to check in a 
third-party archive into the svn because of copyright considerations. The 
images seem to be public domain, but to me, it was not totally clear, whether 
they are. 
Are there any policies regarding this case? I assume, when there are more 
tests, especially with file uploads, the issue might arise again.

Cheers,
Markus

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

Re: [Wikitech-l] Selenium testing framework

[Markus Glaser]

Hi Dan,

the test fails at checking the prerequisites. It tries to load the image page 
and looks for a specific div element which is not present if the image was not 
uploaded correctly (id=filetoc). This might have changed across the versions of 
MediaWiki.

Did you install the PagedTiffHandler extension? It depends on ImageMagick, so 
it might have rejected the upload. Although then it should have produced an 
error message ;) So the other question is, which MediaWiki version do you run 
the tests on? 

Regards,
Markus

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

Re: [Wikitech-l] Selenium testing framework

[Markus Glaser]

Hi Dan,

I had these error messages once when I used Firefox 3.6 for testing. Until 
recently, Selenium did not support this browser. Apparently now they do, but I 
did not have a chance to test this yet. So the solution for me was to point 
Selenium to a Firefox 3.5.

Cheers,
Markus

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

Re: [Wikitech-l] Selenium testing framework

[Markus Glaser]

Hi Dan,

thanks for your feedback, I am very happy that you finally managed to run the 
tests. I also appreciate your suggestions. Adding a port parameter is surely 
useful. As to including the tests in LocalSeleniumSettings.php, I will have a 
look into that. I assume that we have to change the order standards are set in 
RunSeleniumTests.php, since the included tests depend on the PEAR libraries, 
which in turn depend on the PEAR path set above. In the end, I would like to 
include the tests by a command line parameter, thus making the framework more 
flexible. However, I can see that hardcoding the tests in the settings file 
will save some typing work. 

If you want to make the changes yourself, please feel free to do so. I am 
planning to provide an update of the framework with a working example by 
tomorrow evening (about this time), and I will include your suggestions as well 
if you have not done so already :)

Regards,
Markus

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Dan Nessett
Gesendet: Montag, 24. Mai 2010 20:08
An: wikitech-l@lists.wikimedia.org
Betreff: Re: [Wikitech-l] Selenium testing framework

On Sun, 02 May 2010 02:20:06 +0200, Markus Glaser wrote:

> Hi everybody,
> 
> at the Wkimedia Developers' Workshop, I introduced a Selenium testing 
> framework for MediaWiki. Since it has now been promoted to 
> maintenance/tests,  I have provided some initial information it on 
> http://www.mediawiki.org/wiki/SeleniumFramework . I would be very 
> happy about comments and ideas for further improvement. Also, if you 
> intend to use the framework for your tests, please let me know. I will 
> be happy to assist.
> 
> Regards,
> Markus Glaser
> 
> __
> 
> Social Web Technologien
> Leiter Softwareentwicklung
> Hallo Welt! - Medienwerkstatt GmbH
> 
> __
> 
> Untere Bachgasse 15
> 93047 Regensburg
> 
> Tel.  +49 (0) 941 - 56 95 94 - 92
> 
> www.hallowelt.biz<http://www.hallowelt.biz/>
> gla...@hallowelt.biz<mailto:gla...@hallowelt.biz>
> 
> Sitz: Regensburg
> Handelsregister: HRB 10467
> E.USt.Nr.: DE 253050833
> Geschäftsführer:
> Anja Ebersbach, Markus Glaser,
> Dr. Richard Heigl, Radovan Kubani
> 
> __

Hi Markus,

Despite my initial problems getting the Selenium Framework to run, I think it 
is a great start. Now that I have the PagedTiffHandler working, here is some 
feedback on the current framework:

+ When I svn up ../tests (or any ancestor directory), the local changes 
+ I
make to RunSeleniumTests cause a local conflict error. Eventually, many of the 
configuration changes I made should appear in LocalSeleniumSettings, but it 
isn't clear that is possible for all of them. For example, I change the 
commented out set_include_path to include my local PHP/PEAR directory. Can this 
be set in LocalSeleniumSettings? 
Another difference is the include_once() for each test suite. Is it possible to 
move these into LocalSeleniumSettings?

+ It appears there is no way to tell RunSeleniumTests to use a selenium
server port other than . It would be useful to have a -port parameter on 
RunSeleniumServer for this. For example, if there are multiple developers 
working on the same machine, they probably need to use different selenium 
servers differentiated by different port numbers.

I don't mind working on both of these issues, but since you are the original 
architect of the framework, it is probably best for you to comment on them 
first and perhaps suggest what you consider to be the best approach to their 
resolution.

--
-- Dan Nessett


___
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

Re: [Wikitech-l] Mark Hershberger departing Wikimedia Foundation in May

[Markus Glaser]

Thanks, Mark! You were one of my first contacts in the wmdev community and made 
me feel very welcome here. 

Cheers, Markus

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

Re: [Wikitech-l] Hackathon Berlin 2012

[Markus Glaser]

+1
mglaser

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Thomas Gries
Gesendet: Donnerstag, 29. März 2012 22:58
An: Wikimedia developers; Nicole Ebber
Betreff: [Wikitech-l] Hackathon Berlin 2012

Suggestion: git workshop and tutorial @ Hackathon Berlin 2012

___
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

Re: [Wikitech-l] selenium browser testing proposal and prototype

[Markus Glaser]

Some time ago some people from the test framework team started working on a 
Selenium Framework for MediaWiki [1], in PHP and with Selenium 1.0. One of the 
reasons the project discontinued was that there was no clear case of when 
Selenium would be useful as opposed to unit tests, esp. using QUnit and 
TestSwarm for UI testing. I still see some use cases, though:
* Smoketesting the whole application on a very high level
* Testing complex interaction patterns with several page reloads (e.g. maybe 
producing edit conflicts)
* Testing cross-browser compatibility (e.g. using the screenshot feature)
* It's easy to record tests using the Selenium IDE. So basically anyone could 
write tests, esp. for some less used extensions
* This also might be useful when filing bugs (make them reproducible)

While I see the case for new approach based on Ruby and Watir, I still think, 
some of the experiences we made back then could be useful in the design of the 
new testing environment. Here are some points of  what we have so far:
* a (rudimentary) set of methods that generalize login, page calls, page 
preparation with wikitext etc.
* a configuration system to run the tests against different wikis, and also a 
test suite layout that helps to select a subset of tests. 
* a command-line test runner
* a way of reconfiguring the wiki under test so that we can standartize some 
settings, such as language (which is an issue in some cases when testing UI). 
This also provides means to switch the wiki database to a test db and test 
images folder.
* some ideas about the design of tests, suites and individual assertions

I would be happy to contribute and take some of this to the next level within 
the new environment :) 

Cheers, Markus (mglaser)

[1] https://www.mediawiki.org/wiki/Selenium

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Chris McMahon
Gesendet: Donnerstag, 5. April 2012 23:46
An: wikitech-l@lists.wikimedia.org
Betreff: [Wikitech-l] selenium browser testing proposal and prototype

As QA Lead for WMF, one of the things I want to do is to create an 
institutional suite of automated cross-browser regression tests using Selenium. 
 I have two goals for this suite:  first, to make it attractive and convenient 
for the greater software testing community to both use the suite locally and 
also to contribute to it.  Second, to have the suite be a useful regression 
test tool within WMF, tied to Beta Labs and controlled by Jenkins.

For various reasons, I think the best language for this project is Ruby.  I 
realize that is a controversial choice, and I would like to explain my 
reasoning.  First let me address what I think will be the most serious
objections:

** Ruby gems are incompatible with Debian/Ubuntu apt packaging, making it 
difficult or impossible to maintain Ruby code in production.

The selenium test suite is not intended to run on production servers.
 There are two targets for this code.  The first target is users' local 
machines, including and especially Windows users.  The second target is a 
single dedicated headless Labs Ubuntu instance, controlled by Jenkins, serving 
as a client to selenium-server, where selenium-server is running on the various 
Windows etc. VMs that exist today on the WMF VPN.

** It's not PHP.

As of today, PHP has no complete or authoritative implementation of 
selenium-webdriver/Selenium 2.0.  That situation is unlikely to change any time 
soon.  This leaves a choice of Ruby or Python.  For various reasons I think 
Ruby is the superior choice.

** Design goals and their implementation.

In the interest of making this project as attractive as possible to the greater 
testing community, I have defined a browser automation "stack", using the most 
current and accepted practices for browser test automation.
 The stack looks like this:

* Selenium-webdriver low-level "toolbox" API.
* Higher-level API for consistent access to pages and elements without the user 
having to create their own handling for timeouts, exceptions, "stale objects", 
multiple access criteria, etc.
* Modern, BDD-style assertions for pass/fail criteria (as opposed to xUnit 
style assertions)
* "Page Object" design pattern in place and functioning out of the box
* Support for mobile emulators
* Institutional support for Jenkins integration

I submit that having these things in place and working when the user downloads 
the suite is what will make this project attractive to the global testing 
community.

Taking these point by point:

Even as I write this, the W3C is meeting in London to approve webdriver as an 
internet standard, with Selenium 2.0 as the reference implementation of that 
standard.  This means that the selenium 2.0 API is only a fraction the size of 
that of Selenium 1.0, and serves a very different purpose.  The selenium 2.0 
API can be considered a "toolbox" from which higher-level APIs are constructed. 

Re: [Wikitech-l] MediaWiki tarballs and the WMF

[Markus Glaser]

Definitely interested! I have just finished some packaging for the Web App 
Gallery and would like to see (and add) some more flexibility to the installer. 
Also, at SF Hackathon, we had some discussion about the use of MediaWiki by 
outside parties, their issues and how to make their lives easier ;)

Cheers, Markus

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Mark A. 
Hershberger
Gesendet: Mittwoch, 6. Juni 2012 19:36
An: developers, Wikimedia
Betreff: [Wikitech-l] MediaWiki tarballs and the WMF

In the past couple of weeks I've been talking with Sam Reed (WMF's current 
MediaWiki release manager) and Rob Laphiner (WMF's Platform Engineering 
Director) about the future of MediaWiki tarballs.

I began this discussion after Rob expressed regret about the WMF's ability to 
give tarball distribution the attention it deserves.  Since the WMF is focused 
on maintaining Wikipedia and its sister projects, tarball distribution often 
loses among competing priorities.

The Foundation has made MediaWiki available for everyone and that's a great 
thing.  But Wikimedia's funding comes from donations as a result of requests on 
Wikipedia, not from distribution of MediaWiki, so they are rightly focused on 
their production cluster.

Other users of the MediaWiki software have different needs.  For instance, 
Citizendium, and Wikia and have both pegged their MediaWiki installations at 
1.16.5 for stability and made their own modifications
-- essentially forking the code.  Forking is not ideal, but it is 
understandable because there is no cooperation around individual MediaWiki 
releases over the long term.  With a third party to manage MediaWiki releases 
and maintain long term support for selected releases, cooperation between 
non-WMF users would be smoother.

To this start effort, I welcome interested collaborators from the community of 
MediaWiki users outside of the WMF.  With your help, we will start making and 
maintaining MediaWiki releases based on the core MediaWiki code without forking 
development.

I've been discussing this with some MediaWiki sites as well as setting up a 
separate mailing list for packagers (such as Debian and RedHat
distributors) and discussing it there.  So far the response has been positive.

So now I'm asking you guys. Any interest?

--
http://hexmode.com/

Find peace within yourself and there will be peace on heaven and
earth.  -- Abba Isaac

___
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

Re: [Wikitech-l] MediaWiki tarballs and the WMF

[Markus Glaser]

>>Also, at SF
>>Hackathon, we had some discussion about the use of MediaWiki by outside 
>>parties, their issues and how to make their lives easier ;)

> What did your discussions conclude?


Actually, it was even earlier...;) Discussion notes can be found at 
http://www.mediawiki.org/wiki/NOLA_Hackathon/Saturday#Third-party_committers_help

Cheers,
Markus

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

Re: [Wikitech-l] Searching in mediawiki instance with solr?

[Markus Glaser]

Hi Uwe,

the BlueSpice Extension [1] uses Solr to search MediaWiki. 

Cheers,
Markus (mglaser)

[1] http://www.mediawiki.org/wiki/Extension:Blue_spice

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Uwe Baumbach
Gesendet: Dienstag, 7. August 2012 11:45
An: wikitech-l@lists.wikimedia.org
Betreff: [Wikitech-l] Searching in mediawiki instance with solr?

Hi,

is there any special advice for searching in mediawiki instances using solr?

The only thing I found

http://www.mediawiki.org/wiki/Extension:SolrStore

seemed to be quit special for SMW?

We already run solr for other projects and it would be nice to include our wiki

http://genwiki.genealogy.net

Uwe (Baumbach)

___
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] gerrit search

[Markus Glaser]

Hi all,

I am trying to find a (any) html file in gerrit (trying to find out whether it 
is displayed as HTML in a browser, but that is not the issue here…). When I 
enter “html” in the search box, it apparently searches commit messages for html 
(?). When I try the search syntax as described here [1], I get an invalid query 
error. Is there any documentation on what search operators I can use or how the 
search works in general? Any hints are greatly appreciated :)

Cheers,
Markus

[1] http://gerrit.googlecode.com/svn/documentation/2.1.4/user-search.html
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] gerrit search

[Markus Glaser]

Thank you Sumana! I know a lot more about searching in gerrit now, which helps 
a lot in general :)

Cheers,
Markus


-Ursprüngliche Nachricht-
Von: Sumana Harihareswara [mailto:suma...@wikimedia.org] 
Gesendet: Donnerstag, 6. September 2012 19:18
An: Wikimedia developers
Cc: Markus Glaser
Betreff: Re: [Wikitech-l] gerrit search

On 09/05/2012 03:56 PM, Markus Glaser wrote:
> Hi all,
> 
> I am trying to find a (any) html file in gerrit (trying to find out 
> whether it is displayed as HTML in a browser, but that is not the 
> issue here…). When I enter “html” in the search box, it apparently 
> searches commit messages for html (?). When I try the search syntax as 
> described here [1], I get an invalid query error. Is there any 
> documentation on what search operators I can use or how the search 
> works in general? Any hints are greatly appreciated :)
> 
> Cheers,
> Markus
> 
> [1] 
> http://gerrit.googlecode.com/svn/documentation/2.1.4/user-search.html

Hi, Markus.  I looked for the search syntax in the Gerrit docs -- by the way, 
you should probably be looking in 
https://gerrit.wikimedia.org/r/Documentation/user-search.html since that is 
congruent with our installation of Gerrit, version 2.4.2.  I found the 
"file:^REGEX" operator, with the note:

"Currently this operator is only available on a watched project and may not be 
used in the search bar."

I'm sorry for the trouble.  For your purpose, I suggest you create a quick HTML 
page and commit it into the test/mediawiki/extensions/examples repository.

The search examples in the Gerrit documentation are fairly useful.  A few 
searches I often use:

* status: and project: search, as in
https://gerrit.wikimedia.org/r/#/q/status:open+project:^mediawiki.*,n,z
and
https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions/ProofreadPage,n,z

* "what patchsets haven't gotten reviewed yet?" search:
https://gerrit.wikimedia.org/r/#/q/-CodeReview%252B1+-CodeReview%252B2+-CodeReview-1+-CodeReview-2+project:%255Emediawiki.*,n,z

* owner: search, as in
https://gerrit.wikimedia.org/r/#/q/owner:preilly,n,z or 
https://gerrit.wikimedia.org/r/#/q/status:merged+-owner:L10n-bot,n,z
(using minus to exclude localization bot commits)

* searching commit messages, as in
https://gerrit.wikimedia.org/r/#/q/message:performance,n,z

--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Using mediawiki from within the Social networks?

[Markus Glaser]

Hi Yury,

we experimented with MediaWiki as a Facebook-App. Basically this is using MW in 
an iFrame and passing through the Facebook authentication. Articles can be 
liked and commented via FB. When you edit something, it publishes that to the 
user's stream.

Here's a prototype, in German though: 
https://www.facebook.com/ComputerTest/app_242056765902153

Cheers,
Markus


-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Yury Katkov
Gesendet: Montag, 1. Oktober 2012 19:45
An: MediaWiki announcements and site admin list; Wikimedia developers
Betreff: [Wikitech-l] Using mediawiki from within the Social networks?

Hi everyone!

Is it possible to use MediaWiki as a service whereas the UI is located on a 
Facebook app? So all the editing and viewing is take place on a Facebook and 
MediaWiki provide the storage, revision control and lots of extensions?
-
Yury Katkov

___
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

Re: [Wikitech-l] [Testing] Selenium

[Markus Glaser]

Hi Benedikt,

the framework was reworked several times the last few weeks, so I am afraid the 
documentation is slightly out of date. I will update it the next few days. As 
of now, you have to add your test classes to the autoloader and then adapt 
these settings and put it in your LocalSettings.php:

$wgEnableSelenium = true;
$wgGroupPermissions['sysop']['selenium'] = true;
$wgSeleniumTestSuites = array(
'SimpleSeleniumTestSuite',
);
// use no protocol here
$wgSeleniumTestsSeleniumHost = 'localhost';
// use of protocol is mandatory! also, selenium requests a trailing slash
$wgSeleniumTestsWikiUrl = 'http://localhost/phase3/';
$wgSeleniumServerPort = ;
$wgSeleniumTestsWikiUser  = 'WikiSysop';
$wgSeleniumTestsWikiPassword  = 'password';
$wgSeleniumTestsBrowsers = array(
'firefox' => '*chrome d:\\Firefox35\\firefox.exe',
'iexplorer' => '*iexploreproxy',
'opera' => '*chrome /usr/bin/opera',
);
$wgSeleniumTestsUseBrowser = 'firefox';

You can find a sample test in the maintenance/tests/selenium folder, which 
consists of a test case and a test suite. It's the test suite you have to add 
to the autoloader. For the sample test, this has already been done in the trunk.

Cheers,
Markus


-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Benedikt Kaempgen
Gesendet: Dienstag, 3. August 2010 17:38
An: Wikimedia developers
Betreff: [Wikitech-l] [Testing] Selenium

Hello,

In order to test SMW, I would like to try out your Selenium testing framework, 
as described here [1]. 

Two things are not that clear to me:

- "As of now, you have to manually add the test file to 
maintenance/tests/RunSeleniumTests.php. This will be replaced by a command line 
argument in the future." What exactly is one supposed to do here?

- Also, in section "Architecture" some files are mentioned, that I cannot find 
in /trunk/phase3, e.g., selenium/SimpleSeleniumTest oder 
selenium/LocalSeleniumSettings.php.sample. Why is this not the case?

Regards,

Benedikt

[1] http://www.mediawiki.org/wiki/SeleniumFramework


--
Karlsruhe Institute of Technology (KIT)
Institute of Applied Informatics and Formal Description Methods (AIFB)

Benedikt Kämpgen
Research Associate

Kaiserstraße 12
Building 11.40
76131 Karlsruhe, Germany

Phone: +49 721 608-7946
Fax: +49 721 608-6580
Email: benedikt.kaemp...@kit.edu
Web: http://www.kit.edu/

KIT - University of the State of Baden-Wuerttemberg and National Research 
Center of the Helmholtz Association


___
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] Selenium Framework - Question on coding conventions

[Markus Glaser]

Hello everybody,

in order to further develop the selenium framework [1], I need to make a few 
design decisions, especially on coding conventions, which I'd like to discuss 
on this list, since they affect the way of how extension- and core developers 
write their tests.

1) Where are the tests located? I suggest for core to put them into 
maintenance/tests/selenium. That is where they are now. For extensions I propse 
a similar structure, that is /tests/selenium.

2) How are the tests organized? Tests are organized in testing suites. Each 
suite represents a conhesive set of tests. So it is possible to have more than 
one test suite per extension / core area. Test suites are technically classes. 
The files should follow this naming convention: 
<[Subset]>TestSuite.php. The subset is optional. For example, 
in the PagedTiffHandler extension, it would be PagedTiffHandlerTestSuite.php 
and PagedTiffHandlerUploadsTestSuite.php. This should also be the name of the 
class. Alternatively, we could use the word "Selenium" somewhere in there in 
order to be able to divide between unit and selenium tests. In that case I 
suggest to use PagedTiffHandlerSeleniumTestSuite.php and 
PagedTiffHandlerUploadsSeleniumTestSuite.php. Hmmm... this gives pretty long 
names. Any suggestions?

3) How does the framework know there are tests? The tests should be registered 
with the autoloader in the extension entry file. In core, they should be 
registered directly with the autoloader.

4) Which tests should be executed? Since Selenium tests are slow, not every 
test should be executed in each test run. So At the moment, there is a variable 
$wgSeleniumTestSuites which can be set in LocalSettings.php and which contains 
the tests that should be run. If things become more dynamically (e.g. when 
tests should be run on svn commit), there could be a function to add to this 
variable.

5) Aesthetics... There is an awful lot of "Selenium" in the class names, method 
names, file names and variable names. It might be a good idea to use "Sn" 
everywhere except for path names.

Two things need to be kept in mind:
* The idea is to use a similar structure for unit- and selenium tests (selenium 
tests are based on unit tests anyway). I assume at some point, the tests should 
also be compatible with a continuous integration server.
* The wiki that executes the selenium tests is not neccesarily the one that is 
being tested if the tests run against a selenium grid.

If anybody would like to share their opinion on my suggestions, I'd be very 
glad!

Regards,
Markus

[1] http://www.mediawiki.org/wiki/SeleniumFramework (documentation will be 
updated soon..)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Selenium Framework - test run configuration data

[Markus Glaser]

Hi all,

I suggest we have one static class variable Selenium::$settings which is set up 
as an array. This array would be filled in some init function from whatever 
sources we decide on. Then, internally, the configuration mechanisms would not 
change anymore, and we could use the init method to fill the settings from 
globals (as is) or ini files (as Mark propses). Those who use the framework, 
however, would not have to rewrite their code.

Regards,
Markus

Markus Glaser
Social Web Technologien
Leiter Softwareentwicklung
Hallo Welt! - Medienwerkstatt GmbH
__

Untere Bachgasse 15
93047 Regensburg

Tel.   +49 (0) 941 - 56 95 94 92
Fax.  +49 (0) 941 - 50 27 58 13


www.hallowelt.biz
gla...@hallowelt.biz

Sitz: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer:
Anja Ebersbach, Markus Glaser, 
Dr. Richard Heigl, Radovan Kubani


-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von dan nessett
Gesendet: Dienstag, 7. September 2010 17:20
An: Wikimedia developers; Mark A. Hershberger
Betreff: Re: [Wikitech-l] Selenium Framework - test run configuration data

I would be happy to coordinate with you. Up to this point I have been working 
with Markus Glaser and that has gone pretty well. But, I would welcome more 
discussion on issues, architecture and implementation strategy for the 
Framework as well as making sure anything I do fits in with what others are 
doing.

Regards,

Dan

--- On Tue, 9/7/10, Mark A. Hershberger  wrote:

> From: Mark A. Hershberger 
> Subject: Re: Selenium Framework - test run configuration data
> To: "Wikimedia developers" 
> Cc: "Dan Nessett" 
> Date: Tuesday, September 7, 2010, 8:04 AM Dan Nessett 
> 
> writes:
> 
> > Either approach works. But, by going back and forth,
> it makes development
> > of functionality for the Framework difficult.
> 
> I should also point out that what I was planning to do was not hidden.
> I wrote about these changes in my weekly report the Monday before I 
> committed them (http://bit.ly/cqAcqz) and pointed to the weekly report 
> from my Ohloh, Twitter, Identi.ca and Facebook accounts.
> 
> Granted, this is not the same as posting to the mailing list, and for 
> that I apologize.
> 
> Looking back in the archives on gmane, it looks like you are very 
> interested in MW testing.  Since this is a large part of my focus 
> currently as well, perhaps we should coordinate our work?
> 
> Mark.
> 
> --
> http://hexmode.com/
> 
> Embrace Ignorance.  Just don't get too attached.
> 


  

___
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

Re: [Wikitech-l] Selenium Framework - standard directory for selenium tests

[Markus Glaser]

Hi,

I agree. Tests from extensions should follow the pattern

Extensions/EXTENSION/tests/selenium

whereas test for the core should be placed into

maintenance/tests/selenium

Any objections?

Regards,
Markus

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Priyanka Dhanda
Gesendet: Montag, 13. September 2010 21:28
An: wikitech-l@lists.wikimedia.org
Betreff: Re: [Wikitech-l] Selenium Framework - standard directory for selenium 
tests

Hi Dan,

I believe we decided that selenium tests should go under:
Extension/tests/selenium/

-p

On 09/13/2010 12:04 PM, Dan Nessett wrote:
> Are there any standards for where to put selenium tests? Right now the 
> Simple Selenium test is in phase3/maintenance/tests/selenium and the 
> PagedTiffHandler selenium tests are in PagedTiffHandler/selenium. This 
> suggests a convention of putting extension selenium test files in a 
> sub- directory of the top-level directory named 'selenium'. Is that an 
> official convention?
>
>


--
Priyanka Dhanda
Code Maintenance Engineer
Wikimedia Foundation
http://wikimediafoundation.org
San Francisco, CA



___
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

Re: [Wikitech-l] Selenium Framework - standard directory for selenium tests

[Markus Glaser]

Hi Benedikt,

technically speaking, it should not be a problem, since the path to the test 
suites can be given relative to mw root. This holds for the current solution 
(via autoloader) as well as for the upcoming version with ini-files.

Remains the issue of standardization. It seems reasonable to me for large 
extensions to mirror the mw directory structure. So I suggest this for standard 
for extensions:
* Extensions that do mirror the mw directory structure should place the tests 
similar to mw: extensions/EXTENSION/maintenance/tests/selenium
* Extensions that don't should place the tests in  
extensions/EXTENSION/tests/selenium

Regards,
Markus

Markus Glaser
Social Web Technologien
Leiter Softwareentwicklung
Hallo Welt! - Medienwerkstatt GmbH
__

Untere Bachgasse 15
93047 Regensburg

Tel.   +49 (0) 941 - 56 95 94 92
Fax.  +49 (0) 941 - 50 27 58 13


www.hallowelt.biz
gla...@hallowelt.biz

Sitz: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer:
Anja Ebersbach, Markus Glaser, 
Dr. Richard Heigl, Radovan Kubani


-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Benedikt Kaempgen
Gesendet: Freitag, 17. September 2010 08:05
An: Wikimedia developers; pdha...@wikimedia.org
Betreff: Re: [Wikitech-l] Selenium Framework - standard directory for selenium 
tests

Hi,

in SMW we have a maintenance folder just like MW does. Would it be possible to 
have the tests in there, i.e. SemanticMediaWiki/maintenance/tests/selenium (up 
to now, I have put them in there)?

Regards

Benedikt


--
Karlsruhe Institute of Technology (KIT)
Institute of Applied Informatics and Formal Description Methods (AIFB)

Benedikt Kämpgen
Research Associate

Kaiserstraße 12
Building 11.40
76131 Karlsruhe, Germany

Phone: +49 721 608-7946
Fax: +49 721 608-6580
Email: benedikt.kaemp...@kit.edu
Web: http://www.kit.edu/

KIT - University of the State of Baden-Wuerttemberg and National Research 
Center of the Helmholtz Association

-Original Message-
From: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Markus Glaser
Sent: Monday, September 13, 2010 10:28 PM
To: pdha...@wikimedia.org; Wikimedia developers
Subject: Re: [Wikitech-l] Selenium Framework - standard directory for selenium 
tests

Hi,

I agree. Tests from extensions should follow the pattern

Extensions/EXTENSION/tests/selenium

whereas test for the core should be placed into

maintenance/tests/selenium

Any objections?

Regards,
Markus

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Priyanka Dhanda
Gesendet: Montag, 13. September 2010 21:28
An: wikitech-l@lists.wikimedia.org
Betreff: Re: [Wikitech-l] Selenium Framework - standard directory for selenium 
tests

Hi Dan,

I believe we decided that selenium tests should go under:
Extension/tests/selenium/

-p

On 09/13/2010 12:04 PM, Dan Nessett wrote:
> Are there any standards for where to put selenium tests? Right now the 
> Simple Selenium test is in phase3/maintenance/tests/selenium and the 
> PagedTiffHandler selenium tests are in PagedTiffHandler/selenium. This 
> suggests a convention of putting extension selenium test files in a
> sub- directory of the top-level directory named 'selenium'. Is that an 
> official convention?
>
>


--
Priyanka Dhanda
Code Maintenance Engineer
Wikimedia Foundation
http://wikimediafoundation.org
San Francisco, CA



___
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 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

Re: [Wikitech-l] using parserTests code for selenium test framework

[Markus Glaser]

Hi,

here are my thoughts about phpunit and selenium testing.

> The wiki under test is set up with a master database consisting of a single 
> objectcache table.
> The entries of this table specify a test run identifier as primary key 
> and temporary resource identifiers as dependent fields.
If I understand this correctly, this would not allow to test any wikis that are 
running on live sites, e.g. intranet wikis. While I agree that regression 
testing on live sites is not a good idea, I kind of like the notion that after 
setting up a wiki with all the extensions I like to have, I could do some sort 
of "everything up and running"-test. With the concept of using separate testing 
databases and resources, this would be possible without interference with the 
actual data and could even be done at intervals during, say, maintenance 
periods. 

> Setup of a test run requires the creation of the test
> run temporary resources and a entry in the objectcache table. 
Are there already mechanisms for this? I haven't done too much work with the 
objectcache. This is where memcached data is stored, right? So how do I get the 
data that is needed? This question leads me to another one: How do I get the 
testind database and resources? As I see this, it should be part of the testing 
framework to be able to produce the set of data needed from a "normal" MW 
installation. The whole mechanism would actually be something like a backup, so 
we might look into any existing solutions for that.

> When a request is sent to the wiki under test, very early in the request
> processing (e.g., immediately after LocalSettings is processed) a hook is
> called with the provided state information as an argument that accesses
> the objectcache table. The extension function handling the hook switches
> in the temporary resources and returns.
Also, this hook might handle the reconfiguration of the wiki, if needed. So for 
example, testing the PagedTiffHandler requires uploading of tiff files to be 
enabled. However, there might be some security risks, since it is not directly 
obvious in the code which settings are changed. So the hook should only be 
called when $wgEnableSelenium = true. In addition, we could define a 
DontTouchThisSettings.php, which is called even after the hook and holds some 
settings that are holy to the admin of the wiki :) The question is, though, 
would this not become somewhat too complicated?

> After the test run completes, the testing application cleans up the test run 
> by requesting the deletion of the temporary resources and the objectcache 
> table 
> entry associated with the test run.
In some cases, tests will not change any data, e.g. testing dynamic skin 
elements in vector skin. Would it make sense not to tear down the testing 
environment in that case in order to save some time when testing repeatedly? I 
think, there is a conflict between performance and amount of data, but who wins?

In general, it seems to me that we have some similarity with what is called 
wiki family on mediawiki.org. One could see multiple testing environments as a 
set of multiple wikis that share a common codebase [1]. Does anybody have 
experience with wiki families and the object cache rsp. memcached?

I am not sure whether we can use the same codebase as parsertests. I'd rather 
think, parser tests are a special case of what we are sketching here. On the 
other hand, I don't think it is a good idea to have two separate approaches for 
very similar tasks in the code. Do you think it would be feasible to separate 
the preparation part from both parser tests and selenium tests and build both 
of them on a common ground? 

Best regards,
Markus

[1] http://www.mediawiki.org/wiki/Wiki_family#Scenario_2:_Quick_set-up

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

Re: [Wikitech-l] using parserTests code for selenium test framework

[Markus Glaser]

Hi,

since the wiki under test is not neccessarily the wiki running the test, it 
might be useful to visualize that (I have numbered the individual steps to make 
reference to them easier in the discussion):

testrunner wiki under test
-- ---
1.1 start selenium which in 
turn starts a browser to
talk to the wiki under
test
1.2 send request for new test
with unique test id and tests
that will be fired 
   2.1 create cookie with test id
   2.2 create temporal resources 
   according to tests list
   2.3 create test tracker with timestamp
   2.4 return success code
3.1 start testsuites via selenium
3.2 send a lot of individual 
requests according to the tests
   4.1 testrunner is identified by test id
   4.2 reconfigure database and resources
   according to test id
   4.3 ? Do something with memcached ?
   4.4 execute request
   4.5 update timestamp in test tracker
5.1 send a teardown request
   6.1 execute teardown, i.e. delete
   all resources associated with 
   test id
   6.2 delete test tracker
   6.3 return success code
7.1 stop selenium

Now, if something breaks during the test, the test tracker will not be deleted 
and can serve as as basis for a cleanup procedure that is triggered by a 
cronjob.

Is this something we can all agree on? I assume, steps 2.2 (setting up 
temporary test data) and 4.2 (find a mechanism to actually use the test data) 
will be the ones we have to work on now.

Regards,
Markus


-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Ryan Lane
Gesendet: Freitag, 24. September 2010 20:22
An: Wikimedia developers
Betreff: Re: [Wikitech-l] using parserTests code for selenium test framework

> Here is all that is required:
> * a single wildcard entry in Apache configuration
> * one or two lines in LocalSettings.php to pull a DB name from the 
> hostname/path/CLI parameters.
>
> As for cleaning up resources to keep the machine from getting clogged, 
> it's very unlikely that your test wikis will fill up a 
> multi-hundred-gigabyte drive in the middle of a run. If you find that 
> they do, there's still no need to tie cleanup of any particular run to 
> any particular other run.
>
> All you need to know is which runs have completed and can now be cleaned up.
>

I'd like to add some ideas to this thread that were discussed in the Selenium 
meeting this morning. The basic plan we discussed (and I'm sure I'll be 
corrected some on this) is as follows:

When a run begins, it registers itself with the wiki and gets a session back. 
The wiki software, on creating the session, makes a new run specific wiki using 
the wiki family method. The test will pass both the session cookie, and a test 
type cookie, which will dynamically configure the wiki as the tests run. When 
the run is complete, it should notify the wiki that the test run is complete. 
The wiki software will then destroy the session and the dynamically created 
resources. If a run doesn't complete for some reason, a cron can clean up 
resources that haven't been used in some appropriate amount of time.

Respectfully,

Ryan Lane

___
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

Re: [Wikitech-l] using parserTests code for selenium test framework

[Markus Glaser]

Hi,

I recently suggested some scheme for dynamically creating clean wikis for 
Selenium tests, which can be found here: 
http://www.mediawiki.org/wiki/SeleniumFramework#Testing_with_a_clean_database_and_file_state

After some discussion in the Testing group, I would like to elaborate a bit 
further on some of the steps that need to be done:

2.2 Create temporal resources
2.2.1 create a new database with name "se"+testID
2.2.2 create a new images folder with name "se"+testID
2.2.3 populate database and images with template data. there is a standard 
(vanilla) template, but also, test suites can have their own templates, which 
then would be used. this test data should be placed in the same folder as the 
tests, with the same name.

2.3 Create test tracker with timestamp
I suggest we use a textfile called "se"+testID.txt in a folder 
wiki/seRunningTests. The timestamp would be the creation date of the file.

The next important question is, how should the wiki be identified? Brion 
suggested using a subdomain, e.g. "sn"+testID.yourwiki.org. If I understand 
webserver correctly, however, this would need some specific setup. In the 
selenium testing group we were discussion identifying the wiki via cookie. So 
the wiki under test would read the cookie and reconfigure accordingly. The 
reconfiguration would need to take place right after LocalSettings.php, since 
the following call to Setup.php already assumes some configurations as set. As 
far as I know, Priyanka already has written some code to do this.

3.1 start testsuites via selenium
3.1.1 First, the SeleniumTestRunner needs to store the testID in order to 
identify the ressources for teardown. 
3.1.2 Start the test suite

5.1 send teardown request
fetch the testID stored in 3.1.1 and request the wiki under test to teardown 
the ressources for that id

I would be very happy about comments and thoughts. Are we heading in the right 
direction?

Cheers,
Markus

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Markus Glaser
Gesendet: Mittwoch, 29. September 2010 20:02
An: Wikimedia developers
Betreff: Re: [Wikitech-l] using parserTests code for selenium test framework

Hi,

since the wiki under test is not neccessarily the wiki running the test, it 
might be useful to visualize that (I have numbered the individual steps to make 
reference to them easier in the discussion):

testrunner wiki under test
-- ---
1.1 start selenium which in
turn starts a browser to
talk to the wiki under
test
1.2 send request for new test
with unique test id and tests
that will be fired 
   2.1 create cookie with test id
   2.2 create temporal resources 
   according to tests list
   2.3 create test tracker with timestamp
   2.4 return success code
3.1 start testsuites via selenium
3.2 send a lot of individual
requests according to the tests
   4.1 testrunner is identified by test id
   4.2 reconfigure database and resources
   according to test id
   4.3 ? Do something with memcached ?
   4.4 execute request
   4.5 update timestamp in test tracker
5.1 send a teardown request
   6.1 execute teardown, i.e. delete
   all resources associated with 
   test id
   6.2 delete test tracker
   6.3 return success code
7.1 stop selenium

Now, if something breaks during the test, the test tracker will not be deleted 
and can serve as as basis for a cleanup procedure that is triggered by a 
cronjob.

Is this something we can all agree on? I assume, steps 2.2 (setting up 
temporary test data) and 4.2 (find a mechanism to actually use the test data) 
will be the ones we have to work on now.

Regards,
Markus


-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Ryan Lane
Gesendet: Freitag, 24. September 2010 20:22
An: Wikimedia developers
Betreff: Re: [Wikitech-l] using parserTests code for selenium test framework

> Here is all that is required:
> * a single wildcard entry in Apache configuration
> * one or two lines in LocalSettings.php to pull a DB name from the 
> hostname/path/CLI parameters.
>
> As for cleaning up resources to keep the machine from getting clogged, 
> it's very unlikely that your test wikis will fill up a 
> multi-hundred-gigabyte drive in the middle of a run. If you find that 
> they do, there's still no need

Re: [Wikitech-l] Security warning to trunk users running tests

[Markus Glaser]

Aryeh Gregor wrote
> Why are these tests messing with the live database?  For consistency of 
> results, shouldn't they be using a fresh database on each run?

For Selenium tests, it is planned to provide a mechanism that sets up a fresh 
database and image directory per test suite. I will try to implement this as 
modular as possible, so I could image this might become a common basis also for 
the unit tests. 

Cheers,
Markus

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

Re: [Wikitech-l] Removing test suites from trunk

[Markus Glaser]

Hi all,

concerning the selenium part of the tests, I suggest to treat functional tests 
and regression tests differently:
* The framework and test runner should remain in maintenance/tests, since it 
provides a testing infrastructure for MW
* We are working on a MediaWiki smoke test which makes sure the wiki is 
basically up and running. I think, that kind of tests makes perfect sense 
within phase3, since they might also be run by someone who sets up a wiki and 
wants to make sure everything in the installation went ok. Also, extension 
developers could use them to ensure their work didn't break any basic 
functionality.
* Regression tests for bugfixes go to some separate place, since there might be 
a large number of them. I can see Ashar's point, though. Maybe a solution could 
be to put them in a separate tests folder and ignore this one when bundling a 
tarball?
A similar system might also make sense for unit tests.

Cheers,
Markus (mglaser)

On 6 December 2010 12:08, Petr Kadlec  wrote:
> On 6 December 2010 08:47, Ashar Voultoiz  wrote:
>>  - I want to be able to commit a bug fix + associated tests in one 
>> revision without having to fetch the whole phase3 tree.
>
> You don't have to. Subversion supports (since 1.5?) sparse checkouts 
> ,
> allowing you to have only selected parts of a directory checked out in 
> your working copy, which is a feature suitable exactly for scenarios 
> like this one.

Except it is still too inconvenient to use for most cases (yeah I was going to 
suggest it too):
"Subversion 1.5's implementation of shallow checkouts is good but does not 
support a couple of interesting behaviors. First, you cannot de-telescope a 
working copy item. Running svn update --set-depth empty in an infinite-depth 
working copy will not have the effect of discarding everything but the topmost 
directory-it will simply error out. Second, there is no depth value to indicate 
that you wish an item to be explicitly excluded. You have to do implicit 
exclusion of an item by including everything else."


  -Niklas

--
Niklas Laxström

___
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] [Selenium] Issue with importing a test database

[Markus Glaser]

Hello everybody,

for the Selenium Framework I have a very specific database related issue which 
is hard for me to decide. This is the problem:

In order to have a fresh state for every test, we agreed to have a test 
database (and image folder, but this is a sidetrack now) for every test suite 
run. The fresh database is created from a SQL file which can be attached to a 
test as a resource. Now, to make the creation of such SQL files as easy as 
possible, I wanted to be able to simply use SQL dumps created with mysqldump. 
The import of the data is done via the existing databse abstraction layer. I 
use the method DatabaseBase::sourceFile which in turn calls 
DatabaseBase::sourceStream. The problem is now, that some of the SQL INSERT 
statements seem to be too long for this method.

Platonides pointed me to the source of the problem (thanks!). It lies currently 
in line 2506 (Database.php) : $line = trim( fgets( $fp, 1024 ) ); So the lines 
read are limited to 1024 characters. If I remove this limitation, everything 
works fine. PHP manual tells me that the length parameter is optional as of PHP 
version 4.2.0. Since I don't know enough about how fgets works and what its 
security issues are, I wonder, is there a reason not to remove the parameter?

Cheers,
Markus (mglaser)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Selenium] How to use?

[Markus Glaser]

Hi Benedict,

at the moment, the framework is still work in progress, so it is not shipped 
with any current releases (afaik). Also, using it requires some changes in the 
includes folder as well as the new maintenance class, which is not available 
until MW 1.16. But there is hope for you, I know at least one implementation of 
the framework with MW 1.15.3 ;) I put some notes on backporting the framework 
on http://www.mediawiki.org/wiki/Selenium_Framework#Backporting, although this 
may not yet be exhaustive.

Cheers,
Markus

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Benedikt Kaempgen
Gesendet: Donnerstag, 3. Februar 2011 16:17
An: Janesh Kodikara; Wikimedia developers
Betreff: Re: [Wikitech-l] [Selenium] How to use?

Thanks for the quick answer.

Unfortunately, I still don't know how to apply testing to older MW versions.
I am familiar with the documentation, it is good, but does not answer all 
relevant questions. But I will figure out...

Keep up the good work!

Best,

Benedikt


--
Karlsruhe Institute of Technology (KIT)
Institute of Applied Informatics and Formal Description Methods (AIFB)

Benedikt Kämpgen
Research Associate

Kaiserstraße 12
Building 11.40
76131 Karlsruhe, Germany

Phone: +49 721 608-47946 (!new since 1 January 2011!)
Fax: +49 721 608-46580 (!new since 1 January 2011!)
Email: benedikt.kaemp...@kit.edu
Web: http://www.kit.edu/

KIT - University of the State of Baden-Wuerttemberg and National Research 
Center of the Helmholtz Association


-Original Message-
From: wikitech-l-boun...@lists.wikimedia.org
[mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Janesh Kodikara
Sent: Thursday, February 03, 2011 9:11 AM
To: Wikimedia developers
Subject: Re: [Wikitech-l] [Selenium] How to use?


- Original Message -
From: "Benedikt Kaempgen" 
Newsgroups: gmane.science.linguistics.wikipedia.technical
To: 
Sent: Wednesday, February 02, 2011 6:27 PM
Subject: [Selenium] How to use?
I got following for your answer.

Hi Janesh,

We checked with latest trunk and test scripts available only at tests/selenium. 
Earlier test were located at maintenance/tests/selenium but later moved to one 
level up. So now the tests should be available only at tests/selenium level.

The tests were written against latest code because the idea is to regress test 
the system after latest changes. We can use the scripts against older versions 
if there are no major changes which would break the script.

Details of Selenium framework is available at 
http://www.mediawiki.org/wiki/SeleniumFramework and there is a readme file 
which describes the behavior for installer test scripts.

Regards,
Jinesh De Silva 


___
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

Re: [Wikitech-l] [Selenium] Issue with importing a test database

[Markus Glaser]

Hi,

> I think it can be removed safely.
Great to hear!

> Although in this case I would just run mysqldump with --skip-extended-insert 
> so that it doesn't create such long lines.
Yes, I tried that. But there are tables like l10ncache or objectcache that 
store serialized objects which produce long lines even in that case. Still, I 
think that should be a recommendation for creating the dumps.

Cheers,
Markus

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

Re: [Wikitech-l] [Selenium] Issue with importing a test database

[Markus Glaser]

>>> Although in this case I would just run mysqldump with 
>>> --skip-extended-insert so that it doesn't create such long lines.
>> Yes, I tried that. But there are tables like l10ncache or objectcache that 
>> store serialized objects which produce long lines even in that case. Still, 
>> I think that should be a recommendation for creating the dumps.

>Do you really want to dump those caching tables?
Good question... I don't think it's generally necessary. But then again,  I 
think there are two reasons why we should allow for dumps that contain these 
tables:
* it's easy to use plain old mysql dumps. The easier we make it for developers 
to test their code, the better. An alternative would be to provide a dumper 
script that removes these tables or doesn't dump them in the first place. I 
could dive into that if people here think that's a better way to go.
* maybe someone wants to write a regression test that reproduces some specific 
caching issue. I agree this is unlikely, most probably unit tests would be a 
better way here. But then again, the mechanism I am working on might be a 
possible basis for unit test resources as well.
The point is (and I did not see that in my previous post) that even if I skip 
caching tables in the import, there is most certainly one other table which 
might exceed the 1024 byte limit and that is "text".

Cheers,
Markus

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

Re: [Wikitech-l] [Selenium] Structured description of tests?

[Markus Glaser]

Hi Benedict,

one way to make tests more structured and easier to maintain would be to 
provide a standard set of operations within the Selenium Framework. A list of 
suggestions can already be found at 
http://www.mediawiki.org/wiki/SeleniumFramework#Notes_and_further_improvements. 
However, this does not seen to be very exhaustive... If you like to, we could 
join forces in order to create a usable set of standards, since this would be 
the next item on my todo list for the framework, anyway :)

Cheers,
Markus 

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Benedikt Kaempgen
Gesendet: Montag, 14. März 2011 19:03
An: Wikimedia developers
Betreff: [Wikitech-l] [Selenium] Structured description of tests?

Hello,

As I see from [1-4], test descriptions for MW with the Selenium Framework are 
not much structured at the moment. I think, this will make it difficult to 
maintain these tests.

Any suggestions how we could improve this?

For a start, a bachelor student of mine will be looking into how to describe 
system tests for Semantic MediaWiki (and extensions) using categories and 
properties of Semantic MediaWiki. We are planning that tests are derived from 
and link to contents in the user/admin manual.

Regards,

Benedikt 

[1] http://www.mediawiki.org/wiki/Cite_Extension_Test_Plan
[2] http://www.mediawiki.org/wiki/ConfirmEdit_Test_Plan
[3] http://www.mediawiki.org/wiki/New_installer/Test_plan
[4]
http://www.mediawiki.org/wiki/Selenium/Deployment#Automation_work_done_by_th
e_Calcey_team

--
AIFB, Karlsruhe Institute of Technology (KIT)
Phone: +49 721 608-47946
Email: benedikt.kaemp...@kit.edu
Web: http://www.aifb.kit.edu/web/Hauptseite/en 




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

Re: [Wikitech-l] testing of localization

[Markus Glaser]

Hello,

> The right way to do it is to have a test suite: A document that walks
> the translator through all the use cases of the feature so that all
> possible messages permutations and combinations appear.

Possibly, Selenium tests could be helpful. A Selenium test basically acts as a 
remote control for a browser. So a test could walk through most of the cases 
that produces localized messages. Since a Selenium test is client side, though, 
it cannot (re)produce all the errors on a server. So, for example, a missing 
connection to a database could not be triggered. Another thing we might have to 
consider is how to set breakpoints to pause the Selenium test in order to allow 
a translator to check the messages. 

Cheers,
Markus 


-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Soxred93
Gesendet: Dienstag, 22. März 2011 18:51
An: Wikimedia developers
Betreff: Re: [Wikitech-l] testing of localization


On Mar 22, 2011, at 1:32 PM, Amir E. Aharoni wrote:

> 1. Are there currently any tests in the MediaWiki test suite that 
> focus on localization?

The MediaWiki PHPUnit test suites are still very much incomplete, and have yet 
to test a fraction of the MediaWiki code. That said, there are tests that test 
the wfMessage() function and the Message class, including the various 
translations. So if I am understanding your question correctly, the answer is 
somewhat yes.

-X!


___
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

Re: [Wikitech-l] testing of localization

[Markus Glaser]

Hello,

> What would be nice for a first take would be if, from translatewiki, 
> one could click a link that would take one to a list of screens that 
> show the message in question, with the text highlighted even.  
> Even if the only thing we had to work from was a display of the English 
> language texts in context, that would still be a big step up from where 
> we are now.

I think, Selenium provides a screenschot feature. So if we can get Selenium to 
dump screens and name them according to a sensible scheme, that could produce 
the material you ask for. This could then be done for the English language as a 
kind of template screen set and also for the target language, at certain 
points, e.g. before a new minor release comes out. 

Cheers,
Markus 

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Ariel T. Glenn
Gesendet: Mittwoch, 23. März 2011 07:04
An: Wikimedia developers
Betreff: Re: [Wikitech-l] testing of localization

Στις 23-03-2011, ημέρα Τετ, και ώρα 02:03 +0100, ο/η Platonides έγραψε:
> Marcin Cieslak wrote:
> > So having a possibility to have a pre-flight test of the translation 
> > (or even watch the demo of the original in action) is something 
> > Selenium could deinitely help.  In many cases, translators do not 
> > have permission to experience some interface in the live environment 
> > (CheckUser, AbuseFilter, etc.). Could Selenium solve this problem as 
> > well? Is it just mocking up the interface or do I need a instance 
> > behind that is somehow setup somewhere?
> > 
> > //Marcin
> 
> It needs a tests instance.

I've been beating this drum for years (that translators need to be able to see 
their message(s) in context).  But having to watch an automated test suite 
exercise all of the features of an extension in order to check the 5 new 
messages you are translating, seems less than efficient.

What would be nice for a first take would be if, from translatewiki, one could 
click a link that would take one to a list of screens that show the message in 
question, with the text highlighted even.  Even if the only thing we had to 
work from was a display of the English language texts in context, that would 
still be a big step up from where we are now.

Ariel




___
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

Re: [Wikitech-l] New committer

[Markus Glaser]

Hi Robert,

glad to see you around!

Cheers,
Markus

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Sumana 
Harihareswara
Gesendet: Mittwoch, 11. Januar 2012 02:26
An: Wikimedia developers
Betreff: [Wikitech-l] New committer

Robert Vogel (rvogel, User:Osnard) is a web developer at Hallo Welt! and works 
on WindowsAzureSDK, WindowsAzureStorage, ClientSyntaxHighlighter, BibManager, 
and (probably soon) PagedTiffHandler.  He's receiving extensions access.

Welcome, Robert!

--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

___
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

Re: [Wikitech-l] New committer

[Markus Glaser]

Hi DJ Bauch,

I had some trouble with TortoiseSVN and pageant recently after updating SVN to 
1.7 (and the new svn format) on Win7. The solution for me was to update pageant 
to a current version (I think it was 0.62). Maybe this helps you as well?

Regards,
Markus 

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von DJ Bauch
Gesendet: Mittwoch, 11. Januar 2012 18:26
An: Wikimedia developers
Betreff: Re: [Wikitech-l] New committer

Welcome, Robert!
You and I should be crossing paths. I have everything working through version 
1.18 on Windows Azure, except for the media storage. Right this moment I am 
trying to figure out how to get my code committed, but I have been struggling 
with setting up the Subversion access from my Windows 7 box. Any hints or 
pointers on how to set things up may help me transition from a potential to an 
actual contributer.

On Tue, Jan 10, 2012 at 7:26 PM, Sumana Harihareswara  
wrote:
> Robert Vogel (rvogel, User:Osnard) is a web developer at Hallo Welt! 
> and works on WindowsAzureSDK, WindowsAzureStorage, 
> ClientSyntaxHighlighter, BibManager, and (probably soon) 
> PagedTiffHandler.  He's receiving extensions access.
>
> Welcome, Robert!
>
> --
> Sumana Harihareswara
> Volunteer Development Coordinator
> Wikimedia Foundation
>
> ___
> 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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] JavaScript profiling

[Markus Glaser]

Hi all,

I am trying to profile the JavaScript bit of an extension I maintain. Is there 
any recommended method similar to wfProfileIn/Out in MediaWiki? How do you do 
profiling on ResourceLoader?

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

Re: [Wikitech-l] JavaScript profiling

[Markus Glaser]

Thanks a lot for your answers. I wanted to make sure there's no "official MW 
way". Now I know :)

Cheers,
Markus

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Chad
Gesendet: Dienstag, 31. Januar 2012 14:52
An: Wikimedia developers
Betreff: Re: [Wikitech-l] JavaScript profiling

On Tue, Jan 31, 2012 at 8:38 AM, Roan Kattouw  wrote:
> On Tue, Jan 31, 2012 at 2:18 PM, Markus Glaser  wrote:
>> Hi all,
>>
>> I am trying to profile the JavaScript bit of an extension I maintain. Is 
>> there any recommended method similar to wfProfileIn/Out in MediaWiki? How do 
>> you do profiling on ResourceLoader?
>>
> There is no MediaWiki-side support for JS profiling. However, most JS 
> debugging tools in browsers provide function-level JS profiling. I 
> know for a fact that Firebug (a Firefox extension that provides a JS 
> debugger and console) does.
>

The developer tools built into Chrome also have this feature.

-Chad

___
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] MediaWiki 1.22.0 released

[Markus Glaser]

Dear all,

I am happy to announce the availability of the first stable release of the new 
MediaWiki 1.22 release series.

MediaWiki 1.22 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.22 file for the full list of changes
in this version.

Our thanks to everyone who helped to improve MediaWiki by testing the release 
candidates and submitting bug reports.

== What's new? ==
MediaWiki 1.22 includes all changes released in the smaller 1.22wmfX software 
deployments to Wikimedia sites.

=== Anti-spam and countervandalism improvements ===
We're improving countervandalism and anti-spam features:
* The patrolling system has been improved to make the "mark as patrolled" link 
available on any patrollable page or revision, without having to go to 
Special:RecentChanges or Special:NewPages. It is no longer necessary to look up 
the "rcid" URI parameter from these special pages. (Bug 15936)
* Extension:SimpleAntiSpam, a small but harmless shield against the simplest 
forms of spambots, has been merged into core.

===Editing improvements===
* When comparing revisions in the history or when previewing changes while 
editing, "(No difference)" is now shown in place of a diff when the revisions 
are identical. (Bug 14431)
* After a successful edit, the confirmation message "Your edit was saved." is 
now shown. Formerly a separate extension (Extension:PostEdit), this feature is 
now part of the core software. (Bug 48276)

===Upgrades to Vector and other skins===
The old Vector extension has been merged into core, and the extension has been 
discontinued. The new version includes several improvements to both the Vector 
skin and cross-skin features. (Bug 45051) If you were previously using the 
Vector extension, you must uninstall it (the extension, not the skin) before 
upgrading to 1.22.

All skins:
* Section edit links are now displayed next to their respective headings rather 
than along the opposite side of the page. (Bug 41729)
* Lists of templates and categories used on the page, displayed below the edit 
form, are now collapsible. The area with license information, edit summary, and 
related functionality below the edit field has received a minor graphical lift. 
(Bug 43689)
* An "edit warning" is now displayed when the user attempts to leave the edit 
page with unsaved changes, on browsers supporting dialogs.
* Vector skin only:
** Navigation menu subsections are now collapsible.
** Page tabs can now dynamically fold into a dropdown menu when the browser 
window isn't wide enough to fit them.

===Support for Composer===
The Composer PHP dependency manager can now be used to install some extensions. 
It solves many common problems, including finding where to download an 
extension, resolving all of its dependencies and libraries, and selecting the 
right versions. Most MediaWiki extensions do not currently support Composer, 
but this is expected to change.

==Upgrade notices for MediaWiki administrators==
As with every release, there are some routine maintenance and upgrade tasks 
that go beyond the primary installation process.

===PHP JSON extension now required===
Though the minimum PHP version is still 5.3.2, MediaWiki now requires either 
the native JSON extension or the pecl-json-c fork. Most servers already have 
this PHP extension installed and enabled. However, if you administer your own 
server, and the MediaWiki installer says you don't have this extension:
* If you compiled PHP yourself with the --disable-all  configure option, you 
may have to recompile with --enable-json.
* On Red Hat or CentOS, check for the line extension=json.so in /etc/php.ini or 
/etc/php.d/json.ini.
* Ubuntu 13.10, Fedora 19, and other recent Linux distributions package 
pecl-json-c separately, under names such as php5-json (Ubuntu universe) and 
php-pecl-jsonc (Fedora). They no longer include the original JSON extension 
because of licensing concerns.

=== Several ancient skins removed ===
On April 1, 2013, several ancient skins were removed from core (not an April 
Fools' joke): Chick, Classic, MySkin, Nostalgia and Simple.

Nostalgia was the phase I/UseModWiki-like skin, and Classic was the main skin 
before the introduction of the default MonoBook in MediaWiki 1.3 on May 22, 
2004. Dating back to February 2002 both skins existed over a year before 
MediaWiki got its name.

=== Blank system messages must be deleted ===
Blanking a system message (editing it on wiki to remove all content) will no 
longer restore the default value for the message, but instead make it show as 
an empty string in the interface (fixing Bug 14176, "Add ability to disable 
MediaWiki messages"). If you have blank messages on your wiki (check 
Special:AllMessages), you must delete them unless you want them to display as 
empty.

===Protection rights usage has changed===
A new setting ($wgCascadingRestrictionLevels) was added for enabling

Re: [Wikitech-l] Drop support for PHP 5.3

[Markus Glaser]

> We should strongly consider ensuring that the latest stable releases of 
> Ubuntu and probably RHEL (or maybe fedora) can run MediaWiki.
> - Ryan
Kind of agree ;)

I'd like to see the next MediaWiki LTS version (1.23) to support PHP 5.3. 
MW1.23LTS has a scheduled release date at end of April (we might add a week or 
two for safety). After that, no problem from my side (release management) with 
dropping PHP5.3 support.

It might have been said before (tl;dr the whole thread) : a vast majority of 
3rd party MW users still relies on PHP5.3. This is not a reason to block 
future improvements, but a fact to consider well. If we can agree on 1.23LTS 
supporting PHP5.3, imho, that'll do the trick.

Best,
Markus (mglaser)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Scheduled MediaWiki release and known issues

[Markus Glaser]

Hello list,



there is a scheduled maintenance release of MediaWiki on Thursday, 27th of 
February. I would like to take the opportunity to point you to the list of 
known issues [1]. Maybe we can get a few of those fixed until mid of the week?



Best,

Markus



[1] http://www.mediawiki.org/wiki/MediaWiki_1.22/Known_issues

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

[Wikitech-l] MediaWiki Security and Maintenance Releases: 1.22.3, 1.21.6 and 1.19.12

[Markus Glaser]

Hello everyone,

I would like to announce the release of MediaWiki 1.22.3, 1.21.6 and 1.19.12.
These releases fix a number of security related bugs that could affect users 
of MediaWiki. In addition, MediaWiki 1.22.3 is a maintenance release. It fixes 
several bugs. You can consult the RELEASE-NOTES-1.22 file for the full list of 
changes in this version. Download links are given at the end of this email.

== Security fixes ==
* (bug 60771) SECURITY: Disallow uploading SVG files using non-whitelisted
  namespaces. Also disallow iframe elements. User will get an error
  including the namespace name if they use a non- whitelisted namespace.
* (bug 61346) SECURITY: Make token comparison use constant time. It seems like
  our token comparison would be vulnerable to timing attacks. This will take
  constant time.
* (bug 61362) SECURITY: API: Don't find links in the middle of api.php links.

== Bug fixes in 1.22.3 ==

* (bug 53710) Add sequence support for upsert in DatabaseOracle in the same 
way
  as in selectInsert
* (bug 60231, 58719) Various fixes to job running code in Wiki.php: Make it
  async on Windows. Fixed possible "invalid filename" errors on Windows.
  Redirect output to dev/null to avoid hanging PHP.
* (bug 60083) Correct sequence name for fresh Postgres installation. Spotted
  by gebhkla
* (bug 60531) Avoid variable naming conflicts in
  DatabasePostgres::selectSQLText. Spotted by gebhkla
* (bug 60094) Fix rebuildall.php fatal error with PostgreSQL. The fix for
  47055 introduced a fatal error when running rebuildall.php. This is a
  workaround suggested by gebhkla on Bugzilla. It just checks to make sure
  $options is actually an array before calling array_search on it.
* (bug 43817c12) Add error handling if descriptionmsg isn't defined for
  extension.
* (bug 60543) Special:PrefixIndex omits stripprefix=1 for "Next page" link.

Full release notes for 1.22.3:


Full release notes for 1.21.6:


Full release notes for 1.19.12:


For information about how to upgrade, see 


**
   1.22.3
**
Download:
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.3.tar.gz

Patch to previous version (1.22.2), without interface text:
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.3.patch.gz
Interface text changes:
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-i18n-1.22.3.patch.gz

GPG signatures:
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.3.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.3.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.3.patch.gz.sig
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-i18n-1.22.3.patch.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

**
   1.21.6
**
Download:
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.6.tar.gz

Patch to previous version (1.21.3), without interface text:
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.6.patch.gz
Interface text changes:
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-i18n-1.21.6.patch.gz

GPG signatures:
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-core-1.21.6.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.6.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.6.patch.gz.sig
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-i18n-1.21.6.patch.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

**
   1.19.12
**
Download:
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.12.tar.gz

Patch to previous version (1.19.11), without interface text:
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.12.patch.gz
Interface text changes:
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.12.patch.gz

GPG signatures:
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-core-1.19.12.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.12.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.12.patch.gz.sig
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.12.patch.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

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

[Wikitech-l] MediaWiki Security and Maintenance Releases: 1.22.5, 1.21.8 and 1.19.14

[Markus Glaser]

Hello everyone,

I am happy  to announce the release of MediaWiki 1.22.5, 1.21.8 and 1.19.14. 
These are regular security and maintenance releases. Download links are given 
at the end of this email.

== Security ==
* (bug 62497) SECURITY: Add CSRF token on Special:ChangePassword.

== Fixes made in all tarballs ==
* (bug 62467) Set a title for the context during import on the cli.

== Bugfixes in 1.22.5 ==
* Fix custom local MediaWiki:Help values.
* mediawiki.js: Fix documentation breakage.
* (bug 58153) Make MySQLi work with non standard port.
* (bug 53887) Reintroduced a link to help pages in the default sidebar, that
  any sysop can customize by editing [[MediaWiki:Sidebar]] locally. The link
  now points to a mediawiki.org page which is guaranteed to exist. Nothing needs
  to be done on your end, but remember to adjust [[MediaWiki:Sidebar]] for the
  needs of your wikis. Everyone can help with the shared documentation by
  translating: https://www.mediawiki.org/wiki/Special:Translate/agg-Help_pages .
* (bug 53888) Corrected a regression in 1.22 which introduced red links on the
  login page. If you previously installed 1.22.x and have created a local page
  to make the red link blue, write its title as in [[MediaWiki:helplogin-url]]
  if you didn't already. Otherwise, you don't need to do anything, but you can
  translate the help page at https://www.mediawiki.org/wiki/Help:Logging_in .

Full release notes for 1.22.5:
<https://www.mediawiki.org/wiki/Release_notes/1.22>

Full release notes for 1.21.8:
<https://www.mediawiki.org/wiki/Release_notes/1.21>

Full release notes for 1.19.14:
<https://www.mediawiki.org/wiki/Release_notes/1.19>

Public keys:
<https://www.mediawiki.org/keys/keys.html>

**
1.22.5
**
Download:
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.5.tar.gz

Patch to previous version (1.22.4):
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.5.patch.gz

GPG signatures:
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.5.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.5.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.5.patch.gz.sig

**
1.21.8
**
Download:
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.8.tar.gz

Patch to previous version (1.21.7):
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.8.patch.gz

GPG signatures:
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-core-1.21.8.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.8.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.8.patch.gz.sig

**
1.19.14
**
Download:
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.14.tar.gz

Patch to previous version (1.19.13):
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.14.patch.gz

GPG signatures:
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-core-1.19.14.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.14.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.14.patch.gz.sig

Markus Glaser
(Release Management Team)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Tablet skin design

[Markus Glaser]

Hello everyone,

Florence asked me to forward this request to the list, which I am happy to do 
:)

Markus

 Original Message 
Subject:Tablet skin design
Date:   Mon, 31 Mar 2014 21:25:31 +0200
From:   Florence Devouard 
Newsgroups: gmane.org.wikimedia.mediawiki



Hello

A friend of mine is looking for a designer who could work on a responsive 
mediawiki skin for a mediawiki-based website for a company.
The goal would rather be to make the skin best for use on tablets.

Would any of you be interested by such a task ? Or would know someone who 
could ? Or would have pointers for such a skin ?

Please feedback here or to my email address fdevouard @@@ anthere.org

Thanks

Anthere



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

[Wikitech-l] MediaWiki maintenance release 1.19.15 is now available

[Markus Glaser]

Hello everyone,

I would like to announce the release of MediaWiki 1.19.15. This is a 
maintenance release. Download links are given at the end of this email.

== Bugfixes in 1.19.15 ==

* Fixed resetting passwords.
* (bug 58640) Fixed a compatibility issue with PCRE 8.34 that caused pages
  to appear blank or with missing text.

Full release notes for 1.19.15:
<https://www.mediawiki.org/wiki/Release_notes/1.19>

Public keys:
<https://www.mediawiki.org/keys/keys.html>

**
1.19.15
**
Download:
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.15.tar.gz

Patch to previous version (1.19.14):
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.15.patch.gz

GPG signatures:
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-core-1.19.15.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.15.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.15.patch.gz.sig

Notice:
There is no patch file for i18n changes as there are no changes to the 
previous version.

Markus Glaser
(Release Management Team)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Branch REL1_23 created, 1.23.0 release in 6 weeks

[Markus Glaser]

Hello everyone,

this is to announce the REL1_23 branch for the upcoming MediaWiki 1.23.0
release was created. The release is scheduled for 6 weeks from now, no
later than May 29th.

In order to facilitate this, please make sure anything you want in 1.23
is ready within a week. The first release candidate will be published on
April 24th. We'll probably do a couple merges from the WMF branches in
the process of making release candidates, but I'd like to have any major
changes in within the next week.

During the period leading up the release, please consider using the
"critical" severity level ensure any release critical bugs are logged
and tracked.

In addition, please look over
https://www.mediawiki.org/wiki/MediaWiki_1.23 and help update it since
it will be used in our release announcement.

Thanks,

Markus
(Release Management Team)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki Security and Maintenance Releases: 1.22.6 and 1.21.9

[Markus Glaser]

Hello everyone,

I would like to announce the release of MediaWiki 1.22.6 and 1.21.9. This is a 
regular security and maintenance release. Download links are given at the end 
of this email. Please note there is no new release of the 1.19 branch, as it is 
not affected by the security issue.

== Security ==
* (bug 63251) SECURITY: escape sortKey in pageInfo.

== Bugfixes in 1.21.9 ==
* (bug 58640) Fixed a compatibility issue with PCRE 8.34 that caused pages
  to appear blank or with missing text.

Full release notes for 1.22.6:
<https://www.mediawiki.org/wiki/Release_notes/1.22>

Full release notes for 1.21.9:
<https://www.mediawiki.org/wiki/Release_notes/1.21>

Public keys:
<https://www.mediawiki.org/keys/keys.html>

**
1.22.6
**
Download:
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.6.tar.gz

Patch to previous version (1.22.5):
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.6.patch.gz

GPG signatures:
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.6.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.6.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.6.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.

**
1.21.9
**
Download:
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.9.tar.gz

Patch to previous version (1.21.8):
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.9.patch.gz

GPG signatures:
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-core-1.21.9.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.9.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.9.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.


Markus Glaser
(Release Management Team)

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

[Wikitech-l] 1.23.0 release candidate ready for download

[Markus Glaser]

Hello everyone,

we've put together a first RC for 1.23.0.  Please test the tarball and report
any bugs you find on Bugzilla: http://bugzilla.wikimedia.org/

Full release notes:
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/tags/1.23.0rc0/RELEASE-NOTES-1.23
https://www.mediawiki.org/wiki/Release_notes/1.23

**

Download:
http://download.wikimedia.org/mediawiki/1.23/mediawiki-1.23.0rc0.tar.gz

GPG signatures:
http://download.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.0rc0.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.23/mediawiki-1.23.0rc0.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

Markus Glaser
(Release Management Team)

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

[Wikitech-l] MediaWiki 1.23.0-rc.2 release candidate is out

[Markus Glaser]

The second release candidate for 1.23.0 (1.23.0-rc.2) is now available for 
download.

The changes since 1.23.0-rc.1 are as follows:

* (bug 56269) Avoid uncommitted transaction notices in thumb.php and 
img_auth.php.
* (bug 52342) Preference "Remember my login" was removed.
* (bug 65434) Vector: Suppress watch star focus outline when animating it.
* (bug 64289) jquery.textSelection: Don't throw errors on empty collections.
* (bug 36356) Add space between two feed links.
* Reverted fix for (bug 58032) "Introducing pp_sortkey."
* (bug 48084) Fixed a bug in the installer that could cause $wgLogo to hold
  the wrong path to the placeholder logo (skins/common/images/wiki.png).
* Mediawiki.api: Fix API postWithToken method.
* (bug 63444) Made it possible to change the indent string (default: 4 spaces)
  used by FormatJson::encode().

Full release notes:
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/1.23.0-rc.2/RELEASE-NOTES-1.23
https://www.mediawiki.org/wiki/Release_notes/1.23

**

Download:
http://download.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.0-rc.2.tar.gz
http://download.wikimedia.org/mediawiki/1.23/mediawiki-1.23.0-rc.2.tar.gz

GPG signatures:
http://download.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.0-rc.2.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.23/mediawiki-1.23.0-rc.2.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

Markus Glaser
(Release Team)

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

[Wikitech-l] MediaWiki 1.23 release postponed by one week

[Markus Glaser]

Hi everyone,

due to a blocking bug in the installer of the latest release candidate, MW 
1.23.0-rc.2, we decided to release another RC before the final version as soon 
as a patch is available and merged. This also means, the actual release of MW 
1.23.0 will be delayed by one week. New release date is Wednesday, June 4th. 

Best,
Markus 

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

[Wikitech-l] MediaWiki Security and Maintenance Releases: 1.19.16, 1.21.10 and 1.22.7

[Markus Glaser]

Hello everyone,

I would like to announce the release of MediaWiki 1.19.16, 1.21.10 and 1.22.7. 
This is a regular security and maintenance release. Download links are given at 
the end of this email. 

== Security ==
* (bug 65501) SECURITY: Don't parse usernames as wikitext on
  Special:PasswordReset.

== Bugfixes in 1.22.7 ==
* (bug 36356) Add space between two feed links.
* (bug 63269) Email notifications were not correctly handling the
  [[MediaWiki:Helppage]] message being set to a full URL. This is a regression
  from the 1.22.5 point release, which made the default value for it a URL.
  If you customized [[MediaWiki:Enotif body]] (the text of email notifications),
  you'll need to edit it locally to include the URL via the new variable
  $HELPPAGE instead of the parser functions fullurl and canonicalurl; otherwise
  you don't have to do anything.
* Add missing uploadstash.us_props for PostgreSQL.
* (bug 56047) Fixed stream wrapper in PhpHttpRequest.

== Bugfixes in 1.21.10 ==
* (bug 36356) Add space between two feed links.

Full release notes for 1.22.7:
<https://www.mediawiki.org/wiki/Release_notes/1.22>

Full release notes for 1.21.10:
<https://www.mediawiki.org/wiki/Release_notes/1.21>

Full release notes for 1.19.16:
<https://www.mediawiki.org/wiki/Release_notes/1.19>

Public keys:
<https://www.mediawiki.org/keys/keys.html>

**
1.22.7
**
Download:
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.7.tar.gz

Patch to previous version (1.22.6):
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.7.patch.gz

GPG signatures:
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.7.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.7.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.7.patch.gz.sig

**
1.21.10
**
Download:
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.10.tar.gz

Patch to previous version (1.21.9):
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.10.patch.gz

GPG signatures:
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-core-1.21.10.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.10.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.10.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.

**
1.19.16
**
Download:
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.16.tar.gz

Patch to previous version (1.19.15):
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.16.patch.gz

GPG signatures:
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-core-1.19.16.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.16.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.16.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.


Markus Glaser
(Release Team)

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

[Wikitech-l] MediaWiki 1.23.0-rc.3 release candidate is available

[Markus Glaser]

The third (and hopefully final) release candidate for 1.23.0 (1.23.0-rc.3) is 
now available for download.

The changes since 1.23.0-rc.2 are as follows:

* (bug 65225) jquery.suggestions: Handle CSS ellipsis better for IE.
* (bug 65765) Add ar_text to the list from Revision::selectArchiveFields().
* DerivativeContext::setConfig should take a Config object.
* Make abstract Config class truly implementation-agnostic.
* (bug 65748) Officially deprecate skin autodiscovery.

Full release notes:
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/1.23.0-rc.3/RELEASE-NOTES-1.23
https://www.mediawiki.org/wiki/Release_notes/1.23

**

Download:
http://download.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.0-rc.3.tar.gz
http://download.wikimedia.org/mediawiki/1.23/mediawiki-1.23.0-rc.3.tar.gz

GPG signatures:
http://download.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.0-rc.3.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.23/mediawiki-1.23.0-rc.3.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

Markus Glaser
(Release Team)

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

[Wikitech-l] MediaWiki 1.23.0 released

[Markus Glaser]

Hello everyone,

I am happy to announce the availability of the first stable release of the new 
MediaWiki 1.23 release series.

MediaWiki 1.23 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.23 file for the full list of changes in this 
version.

This is a Long Term Support release (LTS) and will be supported until May 2017.

Our thanks to everyone who helped to improve MediaWiki by testing the release 
candidates and submitting bug reports.

== What's new? ==

* MediaWiki 1.23 includes all changes released in the smaller 1.23wmfX software 
deployments to Wikimedia sites.

=== Skin autodiscovery deprecated ===

Skin autodiscovery, the legacy skin installation mechanism used by MediaWiki 
since very early versions (around 2004), has been officially deprecated and 
will be removed in MediaWiki 1.25.
* MediaWiki 1.23 will emit warnings in production if a skin using the 
deprecated mechanism is found.
* See Manual:Skin autodiscovery for more information and a migration guide for 
site admins and skin developers.

=== Notifications ===

With 1.23, MediaWiki starts to behave more like a modern website as regards 
notifications, to keep the editors of your wiki engaged and always up to date 
about what interests them. This used to require several custom settings.
* (bug 45020) Make preferences "Add pages I create and files I upload to my 
watchlist" and "pages and files I edit" true by default.
* (bug 45022) Make preference "Email me when a page or file on my watchlist is 
changed" true by default.
* (bug 49719) Watch user page and user talk page by default.
This will allow your new users to immediately start benefiting from the 
watchlist and email notification features, without needing to first read all 
the docs to find out that they're as useful as they are.

=== Merged extensions ===

Merged into 1.23:
* ExpandTemplates (bug 28264).
* AssertEdit (bug 27841) - documented at API:Assert.

=== Interface ===

* (bug 42026) Add option to only show page creations in Special:Contributions 
(and API).
* Add new special page to list duplicate files, Special:ListDuplicatedFiles.
* (bug 60333) Add new special page listing tracking categories 
(Special:TrackingCategories).

=== Editing ===

* A new special page Special:Diff was added, allowing users to create internal 
links to revision comparison pages using syntax such as Special:Diff/12345, 
Special:Diff/12345/prev or Special:Diff/12345/98765.

=== Help pages ===

With 1.23, MediaWiki begins a process of consolidation of its help pages. Now, 
most are using the Translate extension and can be easily translated and updated 
in hundreds languages.

In the coming months, we'll focus on making more of the central help pages 
translatable and on linking them from the relevant MediaWiki interfaces for 
better discoverability. Please help: add your own translations; update existing 
pages and cover missing MediaWiki topics.

Traditionally, help pages have been scattered on countless wikis and poorly 
translated; most of those on mediawiki.org were migrated with the help of some 
Google Code-in students.

=== CSS refresh for Vector ===

* Various Vector CSS properties have been converted to LESS variables.
* The font size of #bodyContent/.mw-body-content has 
been increased to 0.875em.
* The line-height of #bodyContent/.mw-body-content 
has been increased to 1.6.
* The line-height of superscript (sup) and subscript (sub) are now set to 1.
* The default color for content text (but not the headers) is now #252525; 
(dark grey).
* All headers have updated sizes and margins.
* H1 and H2 headers now use a serif font.
* Body font is "sans-serif" as always.

For more information see Typography refresh.

=== Configuration ===

Add Config and GlobalConfig classes:
* Allows configuration options to be fetched from context.
* Only one implementation, GlobalConfig, is provided, which simply returns 
$GLOBALS[$name]. There can be more classes in the future, possibly a 
database-based one. For convinience the "wg" prefix is automatically added.
* This adds the $wgConfigClass global variable which is used to determine which 
implementation of Config to use by default.
* The ContextSource getConfig and setConfig methods were introduced.

Full release notes:
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/1.23.0/RELEASE-NOTES-1.23
https://www.mediawiki.org/wiki/Release_notes/1.23


**
Download:
http://download.wikimedia.org/mediawiki/1.23/mediawiki-1.23.0.tar.gz

GPG signatures:
http://download.wikimedia.org/mediawiki/1.23/mediawiki-1.23.0.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

Markus Glaser
(Release Team)

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

[Wikitech-l] Proposal for release management

[Markus Glaser]

Hello everyone,

Mark Hershberger and I submitted a proposal for the next year of release 
management:
https://www.mediawiki.org/wiki/Release_Management_RFP/2014/Mark_y_Markus_LLC

In the upcoming year, we want to focus on creating a user group as a central 
hub for all third party related issues with MediaWiki.

We are happy to hear your comments, feedback and ideas.

Best,
Markus
(mglaser)

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

[Wikitech-l] Open issues for next MediaWiki maintenance releases

[Markus Glaser]

Hello everyone,

next week on July, 30th, there will be another set of maintenance releases for 
MediaWiki. There are still some unresolved bugs and changes that are wating to 
be +2'ed. So if you feel like improving MediaWiki tarball releases in the 
upcoming days, you could have a look at these lists:

Open bugs for MW1.23: 
https://bugzilla.wikimedia.org/buglist.cgi?action=wrap&list_id=331203&product=MediaWiki&resolution=---&target_milestone=1.23.x%20release
Fixes that need to be backported:
https://bugzilla.wikimedia.org/buglist.cgi?f1=flagtypes.name&list_id=331206&o1=substring&query_format=advanced&resolution=---&v1=backport

Bugs with extensions:
https://bugzilla.wikimedia.org/buglist.cgi?action=wrap&list_id=331214&product=MediaWiki%20extensions&resolution=---&target_milestone=MW%201.23%20version
https://bugzilla.wikimedia.org/buglist.cgi?action=wrap&list_id=331215&product=MediaWiki%20extensions&resolution=---&target_milestone=MW%201.19%20version
 

Changes in Gerrit that are waiting to be merged:
https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core+branch:REL1_23,n,z
https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core+branch:REL1_22,n,z
https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core+branch:REL1_19,n,z

Thanks for your help!

Markus (mglaser)
Release Team

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

[Wikitech-l] MediaWiki Security and Maintenance Releases: 1.19.18, 1.22.9 and 1.23.2

[Markus Glaser]

Hello everyone,

I would like to announce the release of MediaWiki 1.23.2, 1.22.9 and 1.19.18. 
This is a regular security and maintenance release. Download links are given at 
the end of this email. 

== Security ==
* (bug 68187) SECURITY: Prepend jsonp callback with comment.
* (bug 66608) SECURITY: Fix for XSS issue in bug 66608: Generate the URL used 
for loading a new page in Javascript,instead of relying on the URL in the link 
that has been clicked.
* (bug 65778) SECURITY: Copy prevent-clickjacking between OutputPage and 
ParserOutput.

== Bugfixes in 1.23.2 ==
* (bug 68313) Preferences: Turn stubthreshold back into a combo box.
* (bug 65214) Fix initSiteStats.php maintenance script.
* (bug 67594) Special:ActiveUsers: Fix to work with PostgreSQL.

== Bugfixes in 1.22.9 ==
* (bug 59147) The img_metadata field was not being decoded from bytea into text.

Full release notes for 1.23.2:
<https://www.mediawiki.org/wiki/Release_notes/1.23>

Full release notes for 1.22.9:
<https://www.mediawiki.org/wiki/Release_notes/1.22>

Full release notes for 1.19.18:
<https://www.mediawiki.org/wiki/Release_notes/1.19>

Public keys:
<https://www.mediawiki.org/keys/keys.html>

**
1.23.2
**
Download:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.2.tar.gz

Patch to previous version (1.23.1):
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.2.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.2.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.2.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.2.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.

**
1.22.9
**
Download:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.9.tar.gz

Patch to previous version (1.22.8):
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.9.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.9.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.9.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.9.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.

**
1.19.18
**
Download:
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.18.tar.gz

Patch to previous version (1.19.17):
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.18.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-core-1.19.18.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.18.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.18.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.


Markus Glaser
(Release Management Team)

P.S.: If you are interested in shaping the future of MediaWiki, come join our 
session about a MediaWiki user group at Wikimania: 
http://wikimania2014.wikimedia.org/wiki/Submissions/How_about_a_MediaWiki_Consortium%3F
 . Email us at gla...@hallowelt.biz or m...@nichework.com if you would like to 
participate remotely.

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

[Wikitech-l] MediaWiki for the third party community: get involved!

[Markus Glaser]

Hello everyone,

the Wiki Release Team invites you to get involved in a much needed effort to 
build a separate entity that cares about the third party use of MediaWiki.  We 
ask for your involvement and participation because, as a community, we need to 
drive MediaWiki!

Be a part of something big! 

1.    Join our mailing list of interested people on wikireleaseteam.org [1]
2.    Attend our first meeting [2]:
   Wikimania London
   Sunday, August 10, 2014 at 11:30AM GMT
   Hammerson Room and/or webstreaming     
3.    Help us help you by providing feedback and comments as we work through an 
environmental scan and development roadmap

With the formation of the release team, a first step has been taken to separate 
the releases from the deployment process. Now is the time to tackle the task of 
building and working our way towards an organisation that cares for MediaWiki 
as a software product. This organisation will foster the MediaWiki third-party 
community, facilitate the exchange of ideas and resources among the third-party 
users, advocate the third-party needs, and advise the MediaWiki development 
from the third party perspective.

Spreading open knowledge is not just about content, but also about tools. 
However, third party users of MediaWiki have very specific needs that are 
naturally of minor interest to running Wikimedia sites. These include the 
installer, support for different platforms and databases, integration with 
other software, extension dependencies, and packaging, just to name a few.

Our mission, far from being complete, is just beginning.  With your help and 
involvement we can make an impact to improve MediaWiki for the third party 
community.

Best,
Mark Hershberger and Markus Glaser
Wiki Release Team

[1] http://wikireleaseteam.org/
[2] 
https://wikimania2014.wikimedia.org/wiki/Submissions/How_about_a_MediaWiki_Consortium%3F

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

[Wikitech-l] Open issues for next MediaWiki maintenance releases

[Markus Glaser]

Hello everyone,



next week on August, 27th, there will be another set of maintenance releases 
for MediaWiki. There are still some unresolved bugs and changes that are wating 
to be +2'ed. So if you feel like improving MediaWiki tarball releases in the 
upcoming days, you could have a look at these lists:



Open bugs for MW1.23:

https://bugzilla.wikimedia.org/buglist.cgi?action=wrap&list_id=331203&product=MediaWiki&resolution=---&target_milestone=1.23.x%20release

Fixes that need to be backported (quite a list this time):

https://bugzilla.wikimedia.org/buglist.cgi?f1=flagtypes.name&list_id=331206&o1=substring&query_format=advanced&resolution=---&v1=backport



Bugs with extensions:

https://bugzilla.wikimedia.org/buglist.cgi?action=wrap&list_id=331214&product=MediaWiki%20extensions&resolution=---&target_milestone=MW%201.23%20version

https://bugzilla.wikimedia.org/buglist.cgi?action=wrap&list_id=331215&product=MediaWiki%20extensions&resolution=---&target_milestone=MW%201.19%20version



Changes in Gerrit that are waiting to be merged:

https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core+branch:REL1_23,n,z

https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core+branch:REL1_22,n,z

https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core+branch:REL1_19,n,z



Thanks for your help!



Markus (mglaser)

Release Team

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

[Wikitech-l] Pre-release announcement for MediaWiki releases 1.22.10 and 1.23.3

[Markus Glaser]

Hello everyone,

this is a notice that on 27th August between 20:00-22:00 UTC we will release 
maintenance updates for current and legacy branches of the MediaWiki software. 
Downloads and patches will be available at that time.

Best, 
Markus
Wiki Release Team

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

[Wikitech-l] MediaWiki Security and Maintenance Releases: 1.22.10 and 1.23.3

[Markus Glaser]

Hello everyone,

I would like to announce the release of MediaWiki 1.22.10 and 1.23.3. This is a 
regular maintenance release. Download links are given at the end of this email. 

== Bugfixes in 1.23.3 ==
* (bug 68501) Correctly handle incorrect namespace in cleanupTitles.php.
* (bug 64970) Fix support for blobs on DatabaseOracle::update.
* (bug 66574) Display MediaWiki:Loginprompt on the login page.
* (bug 67870) wfShellExec() cuts off stdout at multiples of 8192 bytes.
* (bug 60629) Handle invalid language code gracefully in 
  Language::fetchLanguageNames.
* (bug 62017) Restore the number of rows shown on Special:Watchlist.
* Check for boolean false result from database query in SqlBagOStuff.

== Bugfixes in 1.22.10 ==
* (bug 64970) Fix support for blobs on DatabaseOracle::update

Full release notes for 1.23.3:
<https://www.mediawiki.org/wiki/Release_notes/1.23>

Full release notes for 1.22.10:
<https://www.mediawiki.org/wiki/Release_notes/1.22>

Public keys:
<https://www.mediawiki.org/keys/keys.html>

**
1.23.3
**
Download:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.3.tar.gz

Patch to previous version (1.23.2):
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.3.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.3.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.3.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.3.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.

**
1.22.10
**
Download:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.10.tar.gz

Patch to previous version (1.22.9):
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.10.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.10.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.10.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.10.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.


Markus Glaser
(Wiki Release Team)

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

Re: [Wikitech-l] I'm leaving the Wikimedia Foundation

[Markus Glaser]

Hey Sumana,

this is really sad news. You know, you were one of my very first contacts in 
the international MediaWiki world! It's hard for me to imagine this world 
without Sumana. The way you draw people into the community is really 
exceptional! 

I wish you all the best for your future and I hope we can nonetheless stay in 
touch somehow, as a community and on a personal level.

Take care,
Markus

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Sumana 
Harihareswara
Gesendet: Freitag, 12. September 2014 18:09
An: Wikimedia developers
Betreff: [Wikitech-l] I'm leaving the Wikimedia Foundation

I write this email with regret to let you know that I've decided to leave the 
Wikimedia Foundation after nearly four years working here, and that my last day 
will be 30 September.

I go into my reasoning and plans in this personal blog post:
http://www.harihareswara.net/sumana/2014/09/12/0

I'm grateful for what I've learned here and will take these lessons wherever I 
go. And I've made many friends here; thank you. I'll remain [[User:Sumanah]] in 
any volunteer work I do onwiki. Quim Gil will be the person to contact for any 
loose threads I leave behind; still, if you have questions for me, the next two 
weeks would be a good time to ask them.

best,
Sumana Harihareswara
​was Volunteer Development Coordinator, then Engineering Community Manager, now 
Senior Technical Writer Wikimedia Foundation 
___
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] User Group Proposal: MediaWiki Cooperation

[Markus Glaser]

Dear Wikitech-l Readers,

spreading open knowledge is not just about content, but also about tools. 
That's the reason we provide MediaWiki as an open source product. Fortunately, 
MediaWiki is used widely outside the Wikimedia world, so the mission is 
fulfilled, right? Well, not quite... Third party users of MediaWiki do have 
very specific needs that are naturally not in the primary focus when running 
Wikimedia sites. 

Over the past few weeks, a group of people has been working on a proposal for a 
User Group that tackles exactly these issues: "We will advocate the needs of 
all users of MediaWiki. Our primary focus will be those who use MediaWiki 
outside the Wikimedia Foundation (WMF). We are a group of MediaWiki enthusiasts 
who care about the development and evolution of the  MediaWiki as a tool for 
everyone." [1]

We have gathered quite a number of supporters and members. There were some 
meetings where we discussed the mission of this group and its purpose. Now we 
are ready to take the next step and apply for official recognition. Before we 
actually start, we are seeking your feedback. Any comments are welcome, here on 
the list and on the discussion page of the group [2].

Cheers,
Markus (mglaser) and Mark (hexmode)

[1] https://www.mediawiki.org/wiki/Groups/Proposals/MediaWiki_Cooperation
[2] https://www.mediawiki.org/wiki/Talk:Groups/Proposals/MediaWiki_Cooperation

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

[Wikitech-l] Open issues for next MediaWiki maintenance releases

[Markus Glaser]

Hello everyone,

next week on September, 24th, there will be another set of security and 
maintenance releases for MediaWiki. There are still some unresolved bugs and 
changes that are wating to be +2'ed. So if you feel like improving MediaWiki 
tarball releases in the upcoming days, you could have a look at these lists:

Open bugs for MW 1.23:
https://bugzilla.wikimedia.org/buglist.cgi?action=wrap&list_id=331203&product=MediaWiki&resolution=---&target_milestone=1.23.x%20release

Fixes that need to be backported:
https://bugzilla.wikimedia.org/buglist.cgi?f1=flagtypes.name&list_id=331206&o1=substring&query_format=advanced&resolution=---&v1=backport

Changes in Gerrit that are waiting to be merged:
https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core+branch:REL1_23,n,z

Thanks for your help!

Markus (mglaser)
Wiki Release Team

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

Re: [Wikitech-l] Open issues for next MediaWiki maintenance releases

[Markus Glaser]

Hi Lewis,

yes, there will be at least one security fix. The respective bugs will be made 
public with the releases.

Best,
Markus

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Are there security fixes due to go in this release?

- -- Lewis Cawte

On 17/09/14 14:56, Markus Glaser wrote:
> Hello everyone,
> 
> next week on September, 24th, there will be another set of security 
> and maintenance releases for MediaWiki. There are still some 
> unresolved bugs and changes that are wating to be +2'ed. So if you 
> feel like improving MediaWiki tarball releases in the upcoming days, 
> you could have a look at these lists:
> 
> Open bugs for MW 1.23: 
> https://bugzilla.wikimedia.org/buglist.cgi?action=wrap&list_id=331203&;
> product=MediaWiki&resolution=---&target_milestone=1.23.x%20release
>
>  Fixes that need to be backported: 
> https://bugzilla.wikimedia.org/buglist.cgi?f1=flagtypes.name&list_id=3
> 31206&o1=substring&query_format=advanced&resolution=---&v1=backport
>
>  Changes in Gerrit that are waiting to be merged: 
> https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core+
> branch:REL1_23,n,z
>
>  Thanks for your help!
> 
> Markus (mglaser) Wiki Release Team
> 
> ___ Wikitech-l mailing 
> list Wikitech-l@lists.wikimedia.org 
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUGZQrAAoJEEOG781yk7ODAqAP/1VzD050BY6vdrgtkIaTJByG
0yGAKPSZTA/VO15cThq+6DJ1Cyqy+esIGpYEzWGPCbab01+x5DPoeNupIQCdBAak
bLu2D2KOnX9xYbh4mnMedjy2/tpNNrpmCR7rDD9teobuYUrLk/cDMKzcde7D6ZO/
mqtWUtEjEJcvVyq9k1IENdQuDz78W45zdl7U0vK6HXGlSy5CDZwNFsCv/0cRZ/nS
+X9KdaYSqJYyVrnHsnayZelda6JkYmuKzLHAWfYIttx4p8+9dIKtkByNDP5v0iNg
IRWtVaIVlBUkzijfcIXaggVDRiAtxDaXUMPwnsRkFyiDokLU1PwZCQdCzx0V3Ofz
0e4r9dhApk82jYnfHQ9NRKExIEW1hye4okyz0sZKInRd8WKx5Bq4pcQVCKgbPiP7
D1djSlqwfUpl/XdFjuAYLkyU0JzDd5V3Su6P51p4fzXkmgspNHrz7hamMME4n3YL
bGsfUH32cnRjulu+NzUkwAfh871FflTceIXuYCZhVTBBVPiAS+ertvjfQo1g4276
wcItWvf+mRFP0wEuvz1/OtH9DtvDP6LudVxOn3KKEOSiAydUyDBdy0FzIVNQR9+O
vIaFrTPVTb7mw69agin3IQSeEXCYgSWZ+0E6RG2MZ+UKWUs1OVnaH1ytFihC1Mbj
ZVIBMIMcAL8QLQdJ/f4z
=tCsc
-END PGP SIGNATURE-

___
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

Re: [Wikitech-l] [Release workflow recommendation] A public releases JSON file.

[Markus Glaser]

Hi Brian,

on mediawiki-enterprise-l, Derric Atzrott suggested we use the respective 
WikiData item for up-to-date MediaWiki version information:

https://www.wikidata.org/wiki/Q83

It's machine readable, could easily be queried and probably converted into 
other formats as needed. It is also very easy to include updating this item 
into our release workflow.

Do you think this fits your needs?

Best,
Markus

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Brian Wolff
Gesendet: Freitag, 19. September 2014 00:54
An: Wikimedia developers
Betreff: Re: [Wikitech-l] [Release workflow recommendation] A public releases 
JSON file.

On 9/18/14, Daniel Friesen  wrote:
> Every once in awhile I've found an idea for a service which would for 
> one reason or another need to know what releases of MediaWiki exist 
> and which ones are obsolete.
>
> As far as I know, we don't have any sort of API or machine readable 
> metadata at all declaring this information for services to use.

Once upon a time we did:
https://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/MWReleases/?pathrev=81635
(I believe that was actually deployed around 1.17-ish).

I guess you could still just fetch
https://www.mediawiki.org/wiki/Template:MW_stable_release_number to get the 
info, but having a json file somewhere sounds like a good idea provided there's 
actually people wanting to use it and it wouldn't inconvenience whomever is 
charged with updating it too much.

--bawolff

___
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

Re: [Wikitech-l] Backing out REL1_24

[Markus Glaser]

Hi Isarra,

> Why is this ahead of schedule? Two months before release
>  seems pretty reasonable to me; 
> You don't want to rush this stuff, especially when 
> balancing with breaking changes in the next release.
It's ahead of the planned release schedule [1] by a few weeks. The real issues 
is, though, that the branching was not announced a week beforehand, as planned. 
As you point out, the whole tarball release of a major version should not be 
done in a rush. This also implies giving developers, especially when it comes 
to extensions, some time ahead to include their work (in progress) into the 
branch without a lot of backporting.

> Also, 1.24 has already had wmf22 branched. Shouldn't this
> mean master should be going onto 1.25 now anyway?

IMHO, the issue is that we have no clear responsibilities here. The Foundation 
sets the date for switching to wmf1.2x+1. Probably this should this be the 
trigger for the 6 week tarball release process. On the other hand, we have a 
monthly tarball release cycle and announced dates for releases which a lot of 
non-WMF users refer to. So we need to coordinate this. Mind you, I do not want 
to totally stick to the 6 week process we have lined out, there is of course 
flexibility. But it needs some coordination before the branching is acually 
made. I assume it is within the responsibilities of WikiReleaseTeam to make 
sure this coordination takes place (in the future). Personally, I also think 
the WikiReleaseTeam should do the acutal branching and communication about this.

Let me be clear about one thing: this is a matter of unclear responsibilites. 
I'm not blaming anyone personally for what they did. Let's clarify the process 
(maybe here on this list) and make _better_ mistakes tomorrow :)

Best,
Marks

[1] https://www.mediawiki.org/wiki/WikiReleaseTeam/Release_timeline
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki Security and Maintenance Releases: 1.19.19, 1.22.11 and 1.23.4

[Markus Glaser]

Hello everyone,

I would like to announce the release of MediaWiki 1.19.19, 1.22.11 and 1.23.4. 
This is a regular security and maintenance release. Download links are given at 
the end of this email. 

== Security ==
* (bug 69008) SECURITY: Enhance CSS filtering in SVG files. Filter 

Re: [Wikitech-l] REL1_24 branched in core

[Markus Glaser]

Hi Greg,

actually, the WikiReleaseTeam/Release process [1] is my  attempt to rewrite the 
release checklist [2], with more specific information about responsibilites and 
timeframes. I will take this opportunity to  continue working on this.  

[1] https://www.mediawiki.org/wiki/WikiReleaseTeam/Release_process
[2] https://www.mediawiki.org/wiki/Release_checklist 

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Greg Grossmeier
Gesendet: Mittwoch, 24. September 2014 02:35
An: Wikimedia developers
Betreff: Re: [Wikitech-l] REL1_24 branched in core

That's it! Thanks, Sumana! :)

Mark/Markus/Kunal: This seems redundant (in some ways) to 
https://www.mediawiki.org/wiki/WikiReleaseTeam/Release_process . And they don't 
crosslink.

Mark/Markus: Can you merge the two pages effectively?

Thanks!


On Tue, Sep 23, 2014 at 5:19 PM, Sumana Harihareswara  wrote:

> https://www.mediawiki.org/wiki/Release_checklist ?
>
> Sumana Harihareswara
> Senior Technical Writer
> Wikimedia Foundation
>
> On Tue, Sep 23, 2014 at 8:17 PM, Greg Grossmeier 
> wrote:
>
> > On Sat, Sep 20, 2014 at 5:24 AM, Antoine Musso 
> wrote:
> >
> > >
> > > I have adjusted CI to take in account REL1_24
> > >
> > >
> > >
> >
> https://gerrit.wikimedia.org/r/#/q/I515b5e21779120ca143a0ed8ec2c99948a
> dec607,n,z
> > >
> > >
> > Is there a page documenting all the little things (like what Antoine 
> > did there ^) that need to happen with each release?
> >
> > --
> > Greg Grossmeier
> > Release Team Manager
> > ___
> > 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
>



--
Greg Grossmeier
Release Team Manager
___
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] MediaWiki Security and Maintenance Releases: 1.19.20, 1.22.12 and 1.23.5

[Markus Glaser]

Hello everyone,

I would like to announce the release of MediaWiki 1.19.20, 1.22.12 and 1.23.5. 
This is a security release. Download links are given at the end of this email. 

== Security ==
* (bug 70672) SECURITY: OutputPage: Remove separation of css and js module 
allowance.

Full release notes for 1.23.5:
<https://www.mediawiki.org/wiki/Release_notes/1.23>

Full release notes for 1.22.12:
<https://www.mediawiki.org/wiki/Release_notes/1.22>

Full release notes for 1.19.20:
<https://www.mediawiki.org/wiki/Release_notes/1.19>

Public keys:
<https://www.mediawiki.org/keys/keys.html>

**
1.23.5
**
Download:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.5.tar.gz

Patch to previous version (1.23.4):
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.5.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.5.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.5.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.5.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.

**
1.22.12
**
Download:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.12.tar.gz

Patch to previous version (1.22.11):
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.12.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.12.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.12.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.12.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.


**
1.19.20
**
Download:
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.20.tar.gz

Patch to previous version (1.19.19):
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.20.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-core-1.19.20.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.20.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.20.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.


Markus Glaser
(Wiki Release Team)

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

Re: [Wikitech-l] Invitation to this Friday's MediaWiki Cooperation G+ hangout

[Markus Glaser]

Hi Željko, hi all,

we are still meeting, in roughly 2.5 hours from now. Here's the current link:

https://plus.google.com/events/cf7ajegl3357ukcc946vnm1j9b8

Obviously, there was a battle between two apps on how to best synchronize a 
calender, which led to repeated cancellation of that event. Some kind of 
automated edit war ;)

Best,
Markus

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Željko Filipin
Gesendet: Donnerstag, 16. Oktober 2014 17:47
An: Wikimedia developers
Cc: MediaWiki for enterprises (mediawiki-enterpr...@lists.wikimedia.org); 
mediawik...@lists.mediawiki.org
Betreff: Re: [Wikitech-l] Invitation to this Friday's MediaWiki Cooperation G+ 
hangout

On Mon, Oct 13, 2014 at 6:46 PM, Mark A. Hershberger 
wrote:

> https://plus.google.com/events/ce30npoet5jkag8ij64ciro6s5s


Is the event canceled?

I get "Oops! This event could not be found. Your URL may be incorrect, or the 
event may have been deleted."

Željko
___
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] Open issues for next MediaWiki maintenance releases

[Markus Glaser]

Hello everyone,

next week on October, 29th, there will be another set of security and 
maintenance releases for MediaWiki. There are still some unresolved bugs and 
changes that are wating to be +2'ed. So if you feel like improving MediaWiki 
tarball releases in the upcoming days, you could have a look at these lists:

Open bugs for MW 1.23:
https://bugzilla.wikimedia.org/buglist.cgi?action=wrap&list_id=331203&product=MediaWiki&resolution=---&target_milestone=1.23.x%20release

Fixes that need to be backported:
https://bugzilla.wikimedia.org/buglist.cgi?f1=flagtypes.name&list_id=331206&o1=substring&query_format=advanced&resolution=---&v1=backport

Changes in Gerrit that are waiting to be merged:
https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core+branch:REL1_19,n,z

Thanks for your help!

Markus (mglaser)
Wiki Release Team

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

[Wikitech-l] MediaWiki 1.24.0 released

[Markus Glaser]

mposer.json file as it will be overwritten on upgrade.

Full release notes:
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/1.24.0/RELEASE-NOTES-1.24
https://www.mediawiki.org/wiki/Release_notes/1.24


**
Download:
http://download.wikimedia.org/mediawiki/1.24/mediawiki-1.24.0.tar.gz

GPG signatures:
http://download.wikimedia.org/mediawiki/1.24/mediawiki-1.24.0.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

Mark Hershberger and Markus Glaser
(Wiki Release Team)

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

[Wikitech-l] MediaWiki Security and Maintenance Releases: 1.23.7, 1.22.14 and 1.19.22

[Markus Glaser]

Hello everyone,

I would like to announce the release of MediaWiki 1.23.7, 1.22.14 and 1.19.22. 
This is a regular security and maintenance release. Download links are given at 
the end of this email. 

== Security fixes ==
* (bugs 66776, 71478) SECURITY:  User PleaseStand reported a way to inject code 
into API clients that used format=php to process pages that underwent flash 
policy mangling. This was fixed along with improving how the mangling was done 
for format=json, and allowing sites to disable the mangling using 
$wgMangleFlashPolicy.
<https://phabricator.wikimedia.org/T68776>
<https://phabricator.wikimedia.org/T73478>

* (bug 70901) SECURITY: User Jackmcbarn reported that the ability to update the 
content model for a page could allow an unprivileged attacker to edit another 
user's common.js under certain circumstances. The user right "editcontentmodel" 
was added, and is needed to change a revision's content model.
<https://phabricator.wikimedia.org/T72901>

* (bug 7) SECURITY: User PleaseStand reported that on wikis that allow raw 
HTML, it is not safe to preview wikitext coming from an untrusted source such 
as a cross-site request. Thus add an edit token to the form, and when raw HTML 
is allowed, ensure the token is provided before showing the preview.  This 
check is not performed on wikis that both allow raw HTML and anonymous editing, 
since there are easier ways to exploit that scenario.
<https://phabricator.wikimedia.org/T73111>

* (bug 7) SECURITY: Do not show log action when the entry is revdeleted 
with DELETED_ACTION. NOTICE: this may be reverted in a future release pending a 
public RFC about the desired functionality. This issue was reported by user 
Bawolff.
<https://phabricator.wikimedia.org/T74222>


== Bugfixes ==
* (bug 71621) Make allowing site-wide styles on restricted special pages a 
config option.
<https://phabricator.wikimedia.org/T73621>

* (bug 42723) Added updated version history from 1.19.2 to 1.22.13
<https://phabricator.wikimedia.org/T44723>

* $wgMangleFlashPolicy was added to make MediaWiki's mangling of anything that 
might be a flash policy directive configurable.

Full release notes for 1.23.7:
<https://www.mediawiki.org/wiki/Release_notes/1.23>

Full release notes for 1.22.14:
<https://www.mediawiki.org/wiki/Release_notes/1.22>

Full release notes for 1.19.22:
<https://www.mediawiki.org/wiki/Release_notes/1.19>

Public keys:
<https://www.mediawiki.org/keys/keys.html>

**
1.23.7
**
Download:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.7.tar.gz
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.7.tar.gz

Patch to previous version (1.23.6):
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.7.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.7.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.7.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.7.patch.gz.sig


**
1.22.14
**
Download:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.14.tar.gz

Patch to previous version (1.22.13):
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.14.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.14.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.14.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.14.patch.gz.sig


**
1.19.22
**
Download:
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.22.tar.gz

Patch to previous version (1.19.21):
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.22.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-core-1.19.22.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.22.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.22.patch.gz.sig

Mark Hershberger and Markus Glaser
(Wiki Release Team)

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

[Wikitech-l] End of lifetime announcement for MediaWiki 1.22

[Markus Glaser]

Hello everyone,

with the release of MediaWiki 1.24, the lifetime of MediaWiki version 1.22 
ends. There will be a final maintenance release on 17th of December, 2014.

The new legacy version is 1.23. Users still using MediaWiki 1.22 are advised to 
upgrade to version 1.24.0 (latest stable) or 1.23.7 (legacy and LTS version).

MediaWiki 1.19 LTS will continue to be supported until May, 2015.

Best,
Mark Hershberger and Markus Glaser
(Wiki Release Team)

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

[Wikitech-l] MediaWiki Security and Maintenance Releases: 1.24.1, 1.23.8, 1.22.15 and 1.19.23

[Markus Glaser]

Hello everyone,

I would like to announce the release of MediaWiki 1.24.1, 1.23.8, 1.22.15 and 
1.19.23. This is a regular security and maintenance release. Download links are 
given at the end of this email. Please note this release marks the end of 
lifetime for MediaWiki 1.22 branch.

== Security fixes in 1.24.1, 1.23.8, 1.22.15 and 1.19.23 ==
* (bug T76686) [SECURITY] thumb.php outputs wikitext message as raw HTML,
  which could lead to xss. Permission to edit MediaWiki namespace is required
  to exploit this.
* (bug T77028) [SECURITY] Malicious site can bypass CORS restrictions in
  $wgCrossSiteAJAXdomains in API calls if it only included an allowed domain as
  part of its name.

== Bugfixes ==
* (bug T74222) The original patch for T74222 was reverted as unnecessary.
* Fixed a couple of entries in RELEASE-NOTES-1.24.
* (bug T76168) OutputPage: Add accessors for some protected properties.
* (bug T74834) Make 1.24 branch directly installable under PostgreSQL.
* Add missing $ in front of variable in OutputPage.php

== Security fixes in extensions ==
* (bug T77624) [SECURITY] Extension:Listings: missing validation in the 
  'name' and 'url' parameters.
* (bug T73111) [SECURITY] Extension:ExpandTemplates: parses user input
  as wikitext and shows a preview, yet it fails to add an edit token to
  the form and check it. This can be exploited as an XSS when 
  $wgRawHtml = true. Note this only affects the 1.19/1.22 branches.
* (bug T76195) [SECURITY] Extension:TemplateSandbox: 
  Special:TemplateSandbox needs edit token when raw HTML is allowed
* (bug T69180) [SECURITY] Extension:Hovercards: XSS in text extracts.
* (bug T73167) [SECURITY] Extension:Scribunto allows cross-origin 
  leakage of data from a wiki through timing
* (bug T71209) [SECURITY] Extension:TimedMediaHandler: Patch getid3 
  library for CVE-2014-2053.

Full release notes for 1.24.1:
<https://www.mediawiki.org/wiki/Release_notes/1.24>
  
Full release notes for 1.23.8:
<https://www.mediawiki.org/wiki/Release_notes/1.23>

Full release notes for 1.22.15:
<https://www.mediawiki.org/wiki/Release_notes/1.22>

Full release notes for 1.19.23:
<https://www.mediawiki.org/wiki/Release_notes/1.19>

Public keys:
<https://www.mediawiki.org/keys/keys.html>

**
1.24.1
**
Download:
https://releases.wikimedia.org/mediawiki/1.24/mediawiki-1.24.1.tar.gz

Patch to previous version (1.24.0):
https://releases.wikimedia.org/mediawiki/1.24/mediawiki-1.24.1.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.24/mediawiki-core-1.24.1.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.24/mediawiki-1.24.1.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.24/mediawiki-1.24.1.patch.gz.sig


**
1.23.8
**
Download:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.8.tar.gz

Patch to previous version (1.23.7):
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.8.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.8.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.8.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.8.patch.gz.sig


**
1.22.15
**
Download:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.15.tar.gz

Patch to previous version (1.22.14):
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.15.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.15.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.15.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.15.patch.gz.sig


**
1.19.23
**
Download:
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.23.tar.gz

Patch to previous version (1.19.22):
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.23.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-core-1.19.23.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.23.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.23.patch.gz.sig


Markus Glaser
(Wiki Release Team)

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

Re: [Wikitech-l] The future of shared hosting

[Markus Glaser]

Hello everyone,

On 19/01/15 06:47, Tim Starling wrote:
> As long as there are no actual reasons for dropping pure-PHP core 
> functionality, 
> the idea of WMF versus shared hosting is a false dichotomy.
I kind of agree. Instead of seeing things in black and white, aka shared 
hosting or not, we should take a look at the needs of users who run their MW on 
a shared hosting. What exactly do they consider "core functionality"? I don't 
think we actually know the answer yet. To me, it seems very likely that MWs on 
shared hosts are a starting base into the MW world. Probably, their admins are 
mostly not technologically experienced. In the near future, most of them will 
want to see VE on their instances for improved user experience. But do they 
really care about wikicode? Or do they care about some functionality that 
solves their problems. I could imagine, templating is one of the main reasons 
to ask for wikicode. Can we, then,  support templating in pure HTML versions of 
parsoid? Are there other demands and solutions? What I mean is: there are many 
shades of [any color you like], in order to make users outside the WMF happy.

I see shared hosts somewhere in a middle position in terms of skills needed to 
run and in terms of dedication to the site. On the "lower" ground, there are 
test instances run on local computers. These can be supported, for example, 
with vagrant setups, in order to make it very easy to get started. On the 
"upper" level, there are instances that run on servers with root access, vms, 
in clouds, etc. They can be supported, for instance, with modular setup 
instructions, packages, predefined machines, puppet and other install scripts 
in order to get a proper setup. So shared hosting is a special case, then, but 
it seems to have a significant base of users and supporters.

While the current SOA approach makes things more complex in terms of 
technologies one needs to support in order to run a setup that matches one of 
the top 5 websites, it also makes things easier in terms of modularity, if we 
do it right. So, for example, we (tm) could provide a lightweight PHP 
implementation of parsoid. Or someone (tm) runs a parsoid service somewhere in 
the net. 

The question is, then, who should be "someone". Naturally, WMF seems to be 
predestined to lay the ground, e.g. by publishing setup instructions, 
interfaces, puppet rules, etc. But there's plenty of room for other initiatives 
(some could even make money out of this :)). An ecosystem around MediaWiki can 
help do the trick. But here's the crucial bit: We will only get a healthy 
ecosystem around MediaWiki, if things are reliable in a way. If the developer 
community and the WMF commits to support such an environment. In the current 
situation, there's so much insecurity I doubt anyone will seriously consider 
putting a lot of effort in, say, a PHP parsoid port (I'd be happy if someone 
proves me wrong).  

So, to make a long story short: Let's look forward and try to find solutions. 
MediaWiki is an amazing piece of software and we should never stop to salutate 
and support the hundreds of thousands of people that are using it as a basis of 
furthering the cause of free knowledge.

Best,
Markus

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Tim Starling
Gesendet: Montag, 19. Januar 2015 06:47
An: wikitech-l@lists.wikimedia.org
Betreff: Re: [Wikitech-l] The future of shared hosting

On 16/01/15 17:38, Bryan Davis wrote:
> The solution to these issues proposed in the RFC is to create 
> independent services (eg Parsoid, RESTBase) to implement features that 
> were previously handled by the core MediaWiki application. Thus far 
> Parsoid is only required if a wiki wants to use VisualEditor. There 
> has been discussion however of it being required in some future 
> version of MediaWiki where HTML is the canonical representation of 
> articles {{citation needed}}.

Parsoid depends on the MediaWiki parser, it calls it via api.php. It's not a 
complete, standalone implementation of wikitext to HTML transformation.

HTML storage would be a pretty simple feature, and would allow third-party 
users to use VE without Parsoid. It's not so simple to use Parsoid without the 
MediaWiki parser, especially if you want to support all existing extensions.

So, as currently proposed, HTML storage is actually a way to reduce the 
dependency on services for non-WMF wikis, not to increase it.

Based on recent comments from Gabriel and Subbu, my understanding is that there 
are no plans to drop the MediaWiki parser at the moment.

> This particular future may or may not be far off on the calendar, but 
> there are other services that have been proposed (storage service, 
> REST content API) that are likely to appear in production use at least 
> for the Foundation projects within the next year.

There is a proposal to move revision storage to Cassandra, p

Re: [Wikitech-l] Gerrit 2.12.2 test instance - PLEASE TEST

[Markus Glaser]

This update will definitely improve our experience with git. As others have 
said before, the inline editing will greatly speed up the review process and 
improve code quality. This is especially true for the extensions, as you now do 
not have to clone a repo or reject the commit just to fix a typo or some coding 
conventions. Thanks for making this happen! 

I found that the behavior of my old search filters has changed. I used to look 
for bluespice status:open to get all open commits in all bluespice repos. This 
however does not work in the test instance, I only get a small subset of the 
commits I need to see. There are ways around this, e.g. ownerin:bluespice 
status:open, so I am not too concerned about it. Am not sure whether it affects 
other extension writers, though.

Cheers,

Markus
(mglaser)

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

[Wikitech-l] Fantastic MediaWikis - Track at Wikimedia Hackathon - CfP

[Markus Glaser]

Hello everyone,

"Fantastic MediaWikis and How to Maintain Them" is a one-day conference track 
designed for people who work with the open source software MediaWiki in their 
organisation, company or business [1]. The conference track is curated by the 
MediaWiki Stakeholders Group and hosted by Wikimedia Austria.

The track is part of Wikimedia's biggest annual tech-event, the Wikimedia 
Hackathon [2]: For three days each year, about 200 developers come together to 
improve MediaWiki. Among the participants are coders from the Wikimedia 
Foundation as well as volunteers from all over the world.

We're using this opportunity to connect the people who work with MediaWiki in 
their enterprise, company, or organisation to the people who actually develop 
the code. We invite all MediaWiki stakeholders - power-users, maintainers, and 
service providers, who have a professional or semi-professional interest in the 
software - to join us for a day full of MediaWiki knowledge and networking!

This is a call for participation. We are specifically looking for contributions 
of your experience in running MediaWikis. These include but are not confined to:

* Use Cases. Tell us how and why you use MediaWiki in a specific area or to 
solve a specific problem.
* Best Practices. Talk about the most effective way you have found to use 
particular MediaWiki features.
* Enhancements. Have you improved MediaWiki to fit your needs? Show us your 
solution.
* Challenges. How can we all add to MediaWiki functionality? Do you have 
specific ideas you want to collaborate on?

Share your experience and submit a presentation here:

https://www.mediawiki.org/wiki/MediaWiki_Stakeholders%27_Group/Fantastic_MediaWikis_CfP

Important dates:

* 20th March 2017: Call for Participation opens
* 5th April 2017: Submission deadline
* 10th April 2017: Notification of acceptance
* 19th - 21st May 2017: Vienna Hackathon

We are looking forward to your submissions!

Best,
Markus (User:Mglaser)
MediaWiki Stakeholders' Group

[1] https://www.wikimedia.at/hackathon/fantastic-mediawikis/
[2] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2017

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

Re: [Wikitech-l] Introducing the MediaWiki Platform Team!

[Markus Glaser]

It's so great to see this happen! The formation of the platform team clearly 
adds emphasis to the fact that MediaWiki is not only underlying Wikipedia and 
its sister projects, but is also widely used by thousands of sites on the 
internet and therefore a product of the Foundation in itself. There are a lot 
of external MediaWiki maintainers have been longing for clear leadership and a 
predictable roadmap for MediaWiki as a software product for quite some time. So 
this is a big step ahead. 

I wish the team a good start and all the best for your work. If there's 
anything the MediaWiki Stakeholders Group can do to assist you, let us know!

Markus
User:Mglaser
MediaWiki Stakeholders' Group

-Ursprüngliche Nachricht-
Von: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von 
Victoria Coleman
Gesendet: Sonntag, 2. April 2017 17:24
An: wikitech-l@lists.wikimedia.org
Betreff: [Wikitech-l] Introducing the MediaWiki Platform Team!

Hello everyone,

I am pleased to share with you the news about the formation of the latest team 
in the Technology department, the MediaWiki Platform team![1]

The MediaWiki Platform team will be tasked with leading maintenance and 
improvements related to the core MediaWiki platform codebase. That includes 
encouraging future development of the MediaWiki platform and addressing the 
technical debt that has accumulated during the 15-year history of MediaWiki.

MediaWiki is an amazing, powerful, and complex open-source software platform. 
The number and variety of extensions, and the wide variety of communities who 
have adopted MediaWiki as their method for knowledge collection and 
dissemination, are a testament to its strength as a software platform.

Like any significant codebase with a long development history, there are 
remnants of design choices and experiments that are no longer in use, and some 
areas of code are in need of modernization. However, at its core is a large 
amount of highly functional, secure, performant code, capable of supporting a 
robust platform through the use of extensions and hooks. There is also a great 
amount of flexibility to adapt to new requirements.

This team will have a more focused purpose than the previous MediaWiki Core 
team.[2]. While the previous team was at times spread too thin, many areas are 
now covered by dedicated teams like Security and Performance. The new MediaWiki 
Platform team will center their efforts on the core codebase. The team will 
also have a dedicated Product Manager who will be creating the platform roadmap 
in collaboration with the team, the Architecture Committee and the MediaWiki 
user community. 

Specific goals for this team are to:

* Assist and encourage development of features for MediaWiki by providing 
developers with a strong core.

* Undertake feature development work which is primarily architectural in nature.

* Facilitate the development and publication of MediaWiki's roadmap to assist 
coordination between internal and external users.

* Maintain and promote guidelines and standards for the MediaWiki core.

I am thrilled that Tim Starling has agreed to lead the team, reporting directly 
to me. He will be joined by Brion Vibber, Kunal Mehta and Brad Jorsch.  The 
team officially launches on Monday April 3, and will complete the hiring and 
onboarding of additional team members in the coming months. Their initial 
workplan will include core support for multi content revisions for the 
Structured Data on Commons project and will be discussed in more detail during 
the upcoming consultation for the Wikimedia Foundation 2017-2018 annual plan.

I am excited by this latest evolution in the structure of the Foundation's 
Engineering group. We will continue to learn from our collective knowledge and 
expertise, and make adjustments to our composition and plans. I appreciate the 
input provided by many in the community that helped inform this decision. I 
also want to thank the members of the Wikimedia Foundation's Product, 
Technology, and Community Engagement departments who were involved in this 
process. In particular, I would like to thank Toby Negrin, Adam Baso, and 
Trevor Parscal - whose support was critical in bringing this plan together.

Join me in welcoming and celebrating our new team!

Victoria

[1] https://www.mediawiki.org/wiki/MediaWiki_Platform_team 

[2] https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team 

___
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

Re: [Wikitech-l] Fantastic MediaWikis - Track at Wikimedia Hackathon - CfP

[Markus Glaser]

Hello all,

just a reminder: the call for participation for "Fantastic MediaWikis and How 
to Maintain Them", a one-day track at the Wikimedia Hackathon in Vienna, ends 
today. So if you intend to submit a presentation, please add yourself to this 
list:

https://www.mediawiki.org/wiki/MediaWiki_Stakeholders%27_Group/Fantastic_MediaWikis_CfP#How_to_submit

All the best,
Markus (User:Mglaser)
MediaWiki Stakeholders' Group

-Ursprüngliche Nachricht-
Von: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von 
Markus Glaser
Gesendet: Montag, 20. März 2017 15:30
An: Wikimedia developers 
Betreff: [Wikitech-l] Fantastic MediaWikis - Track at Wikimedia Hackathon - CfP

[This sender failed our fraud detection checks and may not be who they appear 
to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]

Hello everyone,

"Fantastic MediaWikis and How to Maintain Them" is a one-day conference track 
designed for people who work with the open source software MediaWiki in their 
organisation, company or business [1]. The conference track is curated by the 
MediaWiki Stakeholders Group and hosted by Wikimedia Austria.

The track is part of Wikimedia's biggest annual tech-event, the Wikimedia 
Hackathon [2]: For three days each year, about 200 developers come together to 
improve MediaWiki. Among the participants are coders from the Wikimedia 
Foundation as well as volunteers from all over the world.

We're using this opportunity to connect the people who work with MediaWiki in 
their enterprise, company, or organisation to the people who actually develop 
the code. We invite all MediaWiki stakeholders - power-users, maintainers, and 
service providers, who have a professional or semi-professional interest in the 
software - to join us for a day full of MediaWiki knowledge and networking!

This is a call for participation. We are specifically looking for contributions 
of your experience in running MediaWikis. These include but are not confined to:

* Use Cases. Tell us how and why you use MediaWiki in a specific area or to 
solve a specific problem.
* Best Practices. Talk about the most effective way you have found to use 
particular MediaWiki features.
* Enhancements. Have you improved MediaWiki to fit your needs? Show us your 
solution.
* Challenges. How can we all add to MediaWiki functionality? Do you have 
specific ideas you want to collaborate on?

Share your experience and submit a presentation here:

https://www.mediawiki.org/wiki/MediaWiki_Stakeholders%27_Group/Fantastic_MediaWikis_CfP

Important dates:

* 20th March 2017: Call for Participation opens
* 5th April 2017: Submission deadline
* 10th April 2017: Notification of acceptance
* 19th - 21st May 2017: Vienna Hackathon

We are looking forward to your submissions!

Best,
Markus (User:Mglaser)
MediaWiki Stakeholders' Group

[1] https://www.wikimedia.at/hackathon/fantastic-mediawikis/
[2] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2017

___
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

Re: [Wikitech-l] automated testing with Sikuli?

[Markus Glaser]

Hi, 

while I don't like the idea of introducing more and more testing tools, I can 
still see an interesting use case here: as of now, we have no way to test 
whether a given layout (HTML, JS, CSS) is really rendered the way we want it to 
be, since both Selenium and QUnit make their tests based on DOM, right? Sikuli 
on the other hand seems to be based on screenshots and here we could detect 
broken layout. There is also some kind of similarity algorithm (which I hope is 
configurable) so  that one test could be used in different browsers even if the 
rendering is not identical to the pixel. 

The question is, do we have the need for testing screen layout?

Cheers,

Markus

P.S.: CCing wikitech, since this might be of broader interest.


-Ursprüngliche Nachricht-
Von: Sumana Harihareswara [mailto:suma...@wikimedia.org] 
Gesendet: Dienstag, 30. August 2011 14:02
An: Markus Glaser; Chad Horohoe; Timo Tijhof
Betreff: automated testing with Sikuli?

http://sikuli.org/

Have any of you run across Sikuli before?  Just wanted to point it out to you.  
It might face the same problems as Selenium, though.

--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

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

Re: [Wikitech-l] Brown bag - Selenium Testing

[Markus Glaser]

Hi Jeremy,

I am quite interested in your work, since I wrote part of the core Selenium 
support [1], which is now on hold. So, how does your code relate to the 
SeleniumFramework? What are the main differences? I still think there is a big 
chance in Selenium tests for extension programmers: given the right tools, they 
are very easy to set up. So why don't we just join forces? For a start, if you 
like me to, I could peer review your code.

Cheers, Markus
(mglaser)

[1] http://www.mediawiki.org/wiki/SeleniumFramework


-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Jeremy 
Postlethwaite
Gesendet: Montag, 19. September 2011 17:39
An: Benedikt Kämpgen
Cc: Wikimedia developers
Betreff: Re: [Wikitech-l] Brown bag - Selenium Testing

Hi Benedikt.

I do not know anything about the new QA Lead position status. I only know the 
job has been posted.

The Selenium work I did was for extensions only, since the core code is on hold.

The work I have done has not been committed to core yet. I will post to the 
mailing list when it does go live.

It would be great to get some feedback on my code.

I will also post a wiki page with details on how to implement the Selenium test 
code for other extensions once it gets implemented in core.

Thanks!


On Fri, Sep 16, 2011 at 1:33 PM, Benedikt Kämpgen  wrote:

> Hello Jeremy,
>
> Great that you organised a brown bag lunch on Selenium Testing.
>
> We use Selenium Testing for an extension and I would like to keep up 
> with the status of Selenium Testing for MediaWiki.
>
> I am wondering whether there are information about discussions during 
> this lunch available, somewhere.
>
> Since Wikimania, is there any more information about the fact that 
> "Selenium Unit Testing in the core has been put on hold until we get 
> our new QA Lead"?
>
> Regards,
>
> Benedikt
>
>
> --
> AIFB, Karlsruhe Institute of Technology (KIT)
> Phone: +49 721 608-47946
> Email: benedikt.kaemp...@kit.edu
> Web: http://www.aifb.kit.edu/web/Hauptseite/en
>
>
>
> > -Original Message-
> > From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l- 
> > boun...@lists.wikimedia.org] On Behalf Of Jeremy Postlethwaite
> > Sent: Friday, September 02, 2011 12:49 AM
> > To: wikitech-l@lists.wikimedia.org
> > Subject: [Wikitech-l] Brown bag - Selenium Testing
> >
> > Hi everyone!
> >
> > I would like to hold a brown bag lunch on Selenium Unit Testing for 
> > Mediawiki extensions.
> >
> > I have been using phpunit and Selenium for a few years.
> >
> > Selenium Unit Testing in the core has been put on hold until we get 
> > our
> new
> > QA Lead.
> >
> > I have attached an event to this email for Wednesday, September 7th 
> > from 12:30pm - 1:00pm
> >
> > There will be a small presentation on how we may use Selenium on the 
> > Fundraising extensions.
> >
> > Discussion/questions will follow.
> >
> > Thanks!
> >
> > --
> > Jeremy Postlethwaite
> > jpostlethwa...@wikimedia.org
> > 515-839-6885 x6790
> > Backend Software Developer
> > Brown bag - Selenium Unit Testing
> > Selenium Unit Testing on Mediawiki
> > *When*
> > Wed, September 7, 12:30pm - 1:00pm GMT-07:00
> > *Where*
> > SF Office Sixth floor
> > *Who*
> > .
> > Jeremy Postlethwaite
> > .
> > wikitech-l@lists.wikimedia.org
> > Wikimedia Foundation  
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



--
Jeremy Postlethwaite
jpostlethwa...@wikimedia.org
515-839-6885 x6790
Backend Software Developer
Wikimedia Foundation  
___
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

Re: [Wikitech-l] automated testing with Sikuli?

[Markus Glaser]

> The code I wrote for Selenium Testing of extensions takes screenshots
> and plays them in a slideshow for you after the testing is completed.
> I did this so it would be possible to inspect layouts.

This is a good solution if you trigger the tests manually. For continuous 
integration, though, you would like to have some automated way of inspecting 
layouts. I am pretty positive that Sikuli runs on Hudson, which makes that an 
option.

What I like about the idea is that you could also test some of the more exotic 
browsers where selenium is not available. I was wondering (without looking too 
much into Sikuli) whether it would be a tool for testing mobile interfaces.  

-- Markus


On Mon, Sep 19, 2011 at 11:39 AM, Trevor Parscal wrote:

> I've been aware of this tool for quite a while, and shown it to some 
> other devs around here. I think it's awesome, but I have not had a 
> need for it yet. I think the visual editor may present some cases 
> where this makes sense
> - but generally it seems the most useful for writing tests that 
> involved taking several input actions and expecting a consistent 
> result. Imagine how useless this may be with testing that searing for 
> something in Google returns a search result - the results change 
> constantly, how would you test that? I think it's a cool tool, and we 
> should consider it when testing, but not go out of our way to use it.
>
> - Trevor
>
> On Mon, Sep 19, 2011 at 7:30 AM, Markus Glaser 
> wrote:
>
> > Hi,
> >
> > while I don't like the idea of introducing more and more testing 
> > tools, I can still see an interesting use case here: as of now, we 
> > have no way to test whether a given layout (HTML, JS, CSS) is really 
> > rendered the way we want it to be, since both Selenium and QUnit 
> > make their tests based on
> DOM,
> > right? Sikuli on the other hand seems to be based on screenshots and 
> > here
> we
> > could detect broken layout. There is also some kind of similarity
> algorithm
> > (which I hope is configurable) so  that one test could be used in
> different
> > browsers even if the rendering is not identical to the pixel.
> >
> > The question is, do we have the need for testing screen layout?
> >
> > Cheers,
> >
> > Markus
> >
> > P.S.: CCing wikitech, since this might be of broader interest.
> >
> >
> > -Ursprüngliche Nachricht-
> > Von: Sumana Harihareswara [mailto:suma...@wikimedia.org]
> > Gesendet: Dienstag, 30. August 2011 14:02
> > An: Markus Glaser; Chad Horohoe; Timo Tijhof
> > Betreff: automated testing with Sikuli?
> >
> > http://sikuli.org/
> >
> > Have any of you run across Sikuli before?  Just wanted to point it 
> > out to you.  It might face the same problems as Selenium, though.
> >
> > --
> > Sumana Harihareswara
> > Volunteer Development Coordinator
> > Wikimedia Foundation
> >
> > ___
> > 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
>



--
Jeremy Postlethwaite
jpostlethwa...@wikimedia.org
515-839-6885 x6790
Backend Software Developer
Wikimedia Foundation <http://wikimediafoundation.org/> 
___
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

Re: [Wikitech-l] automated testing with Sikuli?

[Markus Glaser]

> I've been aware of this tool for quite a while, and shown it to some other 
> devs around 
> here. I think it's awesome, but I have not had a need for it yet. I think the 
> visual editor 
> may present some cases where this makes sense
Just being curious, can you elaborate on that? From my experience (I tried 
TinyMCE on MediaWiki ;), would it not be easier to compare the code a visual 
editor produces with the result of the preview mode? I assume it could easier 
be done by comparing the DOM branches, using QUnit or Selenium instead of 
images. 

> - but generally it seems the most useful for writing tests that involved 
> taking several input 
> actions and expecting a consistent result.
I agree. I thought more about testing skin layout, e.g. divs not being rendered 
in the right place in some browsers. For complex interactions, I'd still prefer 
Selenium or other "non-optical" tools.

-- Markus (mglaser)

On Mon, Sep 19, 2011 at 7:30 AM, Markus Glaser  wrote:

> Hi,
>
> while I don't like the idea of introducing more and more testing 
> tools, I can still see an interesting use case here: as of now, we 
> have no way to test whether a given layout (HTML, JS, CSS) is really 
> rendered the way we want it to be, since both Selenium and QUnit make 
> their tests based on DOM, right? Sikuli on the other hand seems to be 
> based on screenshots and here we could detect broken layout. There is 
> also some kind of similarity algorithm (which I hope is configurable) 
> so  that one test could be used in different browsers even if the rendering 
> is not identical to the pixel.
>
> The question is, do we have the need for testing screen layout?
>
> Cheers,
>
> Markus
>
> P.S.: CCing wikitech, since this might be of broader interest.
>
>
> -Ursprüngliche Nachricht-----
> Von: Sumana Harihareswara [mailto:suma...@wikimedia.org]
> Gesendet: Dienstag, 30. August 2011 14:02
> An: Markus Glaser; Chad Horohoe; Timo Tijhof
> Betreff: automated testing with Sikuli?
>
> http://sikuli.org/
>
> Have any of you run across Sikuli before?  Just wanted to point it out 
> to you.  It might face the same problems as Selenium, though.
>
> --
> Sumana Harihareswara
> Volunteer Development Coordinator
> Wikimedia Foundation
>
> ___
> 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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Brown bag - Selenium Testing

[Markus Glaser]

Hi Jeremy,

> There is a dropbox folder within the extension tests folder that allows 
> developers 
> to record Selenese with the Firefox add-on Selenium IDE. You can place the 
> recorded 
> macros in the folder and they will be picked up by the unit tests if it is 
> desired.

I like the idea of a dropbox for selenese. Do you have to do any conversion in 
order to get it work with your setup?

> It would be great if you could do code review once it is committed.

Sure, just give me a note when it is committed.

Cheers,
Markus


-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Jeremy 
Postlethwaite
Gesendet: Mittwoch, 21. September 2011 19:06
An: Wikimedia developers
Betreff: Re: [Wikitech-l] Brown bag - Selenium Testing

Hi Markus,

That would be great if we could work together on the Selenium testing.

I requested commit access to core today.

If it takes a while to get core access, I may ask Ryan Kaldari to commit my 
code (I sit next to him in the San Francisco office). I wrote Selenium Unit 
Tests for CentralNotice, an extension, Kaldari is quite familiar with.

It would be great if you could do code review once it is committed.

Here is some info about the test code:

The unit tests do use the existing PHPunit testing code, but not the existing 
Selenium code in core.

I have added the class:

ExtensionsSeleniumTestCase extends PHPUnit_Extensions_SeleniumTestCase

I am using:

$wgEnableSelenium = true;

In LocalSettings.php so the code will be picked up when you run 
$IP/tests/phpunit/phpunit.php.

In other projects outside of Wikimedia, I have set up unit tests to run on 
localhost, development and production environments. I did this by setting an 
environment variable with one of the following values:

APPLICATION_ENVIRONMENT = "localhost"
APPLICATION_ENVIRONMENT = "development"
APPLICATION_ENVIRONMENT = "production"

This variable was set in Apache httpd and on the command line.

The Selenium Unit Testing code takes screen shots and plays them in a 
slideshow, so it is sometimes handy to test on live systems. Consequently, you 
have to flag unit testing code as available for production, development or 
localhost. By default all code is considered unsafe for production, so you must 
flag a method as available for production testing.

I also created custom configuration files that live in the tests folder of the 
extension. There is a default file that will be used if a custom file is not 
set:

PSEUDO CODE

if ( file_exists( "selenium.ini" ) ) {

loadConfiguration( "selenium.ini" ); } else {
loadConfiguration( "selenium.ini.dist" ); }

This file controls which browser gets run and allows for a developer of the 
extension to set other info dependent on their tests.

There is a dropbox folder within the extension tests folder that allows 
developers to record Selenese with the Firefox add-on Selenium IDE. You can 
place the recorded macros in the folder and they will be picked up by the unit 
tests if it is desired.

I think working on unit testing code is a lot of fun, so I look forward to 
getting this in to core.

- Jeremy

On Mon, Sep 19, 2011 at 3:27 PM, Markus Glaser  wrote:

> Hi Jeremy,
>
> I am quite interested in your work, since I wrote part of the core 
> Selenium support [1], which is now on hold. So, how does your code 
> relate to the SeleniumFramework? What are the main differences? I 
> still think there is a big chance in Selenium tests for extension 
> programmers: given the right tools, they are very easy to set up. So 
> why don't we just join forces? For a start, if you like me to, I could peer 
> review your code.
>
> Cheers, Markus
> (mglaser)
>
> [1] http://www.mediawiki.org/wiki/SeleniumFramework
>
>
> -Ursprüngliche Nachricht-
> Von: wikitech-l-boun...@lists.wikimedia.org [mailto:
> wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Jeremy 
> Postlethwaite
> Gesendet: Montag, 19. September 2011 17:39
> An: Benedikt Kämpgen
> Cc: Wikimedia developers
> Betreff: Re: [Wikitech-l] Brown bag - Selenium Testing
>
> Hi Benedikt.
>
> I do not know anything about the new QA Lead position status. I only 
> know the job has been posted.
>
> The Selenium work I did was for extensions only, since the core code 
> is on hold.
>
> The work I have done has not been committed to core yet. I will post 
> to the mailing list when it does go live.
>
> It would be great to get some feedback on my code.
>
> I will also post a wiki page with details on how to implement the 
> Selenium test code for other extensions once it gets implemented in core.
>
> Thanks!
>
>
> On Fri, Sep 16, 2011 at 1:33 PM, Benedikt Kämpgen < 
> benedikt.kaemp...@kit.edu
> &g

Re: [Wikitech-l] Upcoming VipsScaler deployment

[Markus Glaser]

On Wed, Nov 2, 2011 at 10:08 PM, Rob Lanphier  wrote:
>> Step 1: Deploy VipsScaler extension, but only use it for PNGs over 
>> 12.5MP and/or TIFFs (which currently generate errors).  Let this sit 
>> in production a while, fixing any bugs we find with this 
>> configuration.

> I should note that PagedTiffHandler currently does support vips, but only 
> unconditionally; 
> we can't choose to only scale images with vips that are currently too large. 
> If tiff support is 
> to be enabled in the first step, then PagedTiffHandler should somehow be 
> interfacing with 
> VipsHandler, which does allow conditional scaling.

It should not be that much of a problem to add conditional use of vips to 
PagedTiffHandler. But I need to understand this a bit better :) So images that 
are bigger than a given threshold size (say, $wgPagedTiffHandlerUseVipsMinSize) 
should use vips as a scaler, below that threshold imagemagick should be used? 
Or can this value be determined dynamically from the vips handler?

Markus
(mglaser)

___
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

Re: [Wikitech-l] New committer

[Markus Glaser]

> Alexander Gesinn (planetenxin) now has extensions access.  

Hi Alex, nice to see you around!

Markus 
(mglaser)

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

Re: [Wikitech-l] Do we need Selenium for anything anymore? (was: [Selenium] IDE test for regressing bug)

[Markus Glaser]

Hello everybody,

that's also the way I see it. Selenium tests do test the application as a 
whole. While I agree that a lot of things that are currently tested with 
Selenium can be substituted with QUnit or similar, I still think that selenium 
tests should be used to check more complex interaction patterns. In BlueSpice, 
an extension I am maintaining, we use Selenium e.g. to test a file uploader or 
GUI elements that interact via AJAX with the server. 

Also, keep in mind that selenium tests are quite easy to record. While 
experienced developers like us probably tend to write the tests instead of 
recording, I think that we can actually reduce the barrier for others.

Regarding the core code, I think we could easily remove the autoloader 
references from the core since they can be put into the SeleniumFramework 
itself. However, there is a call to includes/SeleniumWebSettings.php right 
after LocalSettings are loaded. This file's task is to reconfigure the wiki and 
its database and files when it is under test in order to start with a fresh or 
otherwise defined state. This mechanism is not specific to selenium, although 
currently only used by SeleniumFramework. For Selenium tests to make sense, I 
suggest this mechanism should stay in core. However, we could rename it to 
something more descriptive. 

Btw, there will be a panel in Haifa where we want to discuss the test 
environment as a whole, if anyone's interested :)

Cheers,
Markus


-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Brion Vibber
Gesendet: Donnerstag, 7. Juli 2011 19:43
An: Wikimedia developers
Betreff: Re: [Wikitech-l] Do we need Selenium for anything anymore? (was: 
[Selenium] IDE test for regressing bug)

On Thu, Jul 7, 2011 at 8:28 AM, Chad  wrote:

> On Thu, Jul 7, 2011 at 11:23 AM, Sumana Harihareswara 
>  wrote:
> > Thanks for the test & test suite!  Just wanted to update you that it
> seems
> > like fewer and fewer MediaWiki developers are interested in Selenium
> tests,
> > and many are moving to other tools for automatic testing:
> >
>
> That being said: is there any reason to leave the Selenium support in 
> core anymore?
>

I believe work still needs to be done to provide a test harness that uses QUnit 
for 'live-wiki' tests -- the current QUnit tests are standalone and run from 
static files, so can't test interaction with server-side behavior.

With our current QUnit tests you can see if your JS code does something on some 
input data or HTML you construct, but you can't, say, confirm that issuing a 
click event on the watch tab submits an API request and comes back with the 
expected result.

Interaction tests also tend to modify data -- by performing edits, creating 
accounts, changing settings, deleting things, undeleting things, etc. So, like 
the parser & phpunit tests that are potentially destructive, they either need 
to run on dedicated testing sites where that's acceptible, or the test harness 
needs to be able to set up / tear down a temporary wiki copy. Unlike the parser 
& unit tests, that temporary copy has to be actually exposed via the web so 
client-side tests can run.

-- brion
___
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

Re: [Wikitech-l] On third-party users of MediaWiki and collaboration with upstream

[Markus Glaser]

Hello,

at Hallo Welt!, we are currently discussing some similar issues. The question 
is how deep we should and could tie in with mediawiki svn in general. Here are 
some things that came to my mind:

Changes to core: While BlueSpice is essentially a MediaWiki extension and has a 
policy of accepting MW core as it is, we do have a handful  core hacks where 
necessary. I doubt, though, that these will make it into core. For example, we 
use read protection of pages. A list of changes to core code that are necessary 
in this respect can already be found on mediawiki.org, however, they are not 
permanently implemented, I assume because of performance questions. Similar 
issues arise when you want to use real names instead of usernames. Here we'd 
have to hook at places that seem to be rather performance critical. Having said 
this, I admit, I never tried to pace those hooks in core. You might call that 
preemptive policy compliance... or just laziness  ;). So the question is, can 
there be 'flavors' of MediaWiki that do not have to consider the requirements 
of a high performance high traffic environment? I assume that flavoring MW 
would get rather complicated. But we could introduce hooks that are only 
executed if, say, $wgExecuteExpensiveHooks is set.

Another question is about extensions: I would very much like to see BlueSpice 
in mediawiki svn. There are some difficulties, though. One of them is that we 
use large third party frameworks and I am not sure I want to maintain them in 
mediawiki svn (e.g. TinyMCE or ExtJs), nor if I am allowed to do so legally. 
These could be left out, but then the extension would not be in a working 
condition when downloaded. Another issue is that we want to maintain release 
versions of the extension and backport some bug- and security fixes. That 
basically means branching. And afaik we cannot do that in mediawiki svn. I 
faintly remember having heard about an architecture, where you can kind of hook 
a remote repository into some subversion repository. That might be a solution 
here, since we could keep our own repo and branches while making sure there is 
an upstream of our trunk version. Actually, this sounds very much like DVCS, 
but I admit I don't know enough about git and others to know if that would 
solve this problem. I assume, though, that e.g. Semantic MediaWiki has some 
similar versioning issues, so I would be very interested to hear their thoughts 
on that.

Cheers,
Markus (mglaser)

Von: Jack Phoenix [mailto:j...@countervandalism.net]
Gesendet: Mittwoch, 17. August 2011 20:07
An: Wikimedia developers; Sean Colombo; Jack Herrick; reu...@wikihow.com; 
joachim.b...@twoonix.com; Markus Glaser
Betreff: On third-party users of MediaWiki and collaboration with upstream


Hi all,

while MediaWiki has been and is developed primarily with Wikimedia Foundation's 
interests in mind, there are some big third-party users of MediaWiki out there; 
while Wikia and wikiHow are the biggest and most well-known, they certainly 
aren't the only ones.

What's common to third-party users of MediaWiki is not just custom extensions, 
but sadly core changes, or as they're better known, core hacks -- unsupported 
changes to the core of the MediaWiki software. I think that everyone will agree 
with me when I say that we will want to reduce the amount of core hacking by 
third-parties and instead increase collaboration with us, the upstream 
developers of MediaWiki.

Reducing the amount of core hacks is generally a good idea for third parties, 
because it will allow them to upgrade to the latest stable version of MediaWiki 
easily and things like new hooks can and in many cases are useful to other 
users of MediaWiki. For example, the MakeGlobalVariablesScript hook 
(http://www.mediawiki.org/wiki/Manual:Hooks/MakeGlobalVariablesScript) was 
originally introduced by Wikia (under the name 'ExtendJSGlobalVars'); in r38397 
I added the hook into core under its current name and right now there are many 
extensions using the hook, including ones used by Wikimedia Foundation sites 
(see 
http://www.mediawiki.org/wiki/Category:MakeGlobalVariablesScript_extensions). 
This is a fine example of how a third-party core hack became a part of the 
MediaWiki core and thus something useful to other users of MediaWiki, including 
the Wikimedia Foundation.

Another factor to take into account is security. According to the Version 
lifecycle page on MediaWiki.org (see 
http://www.mediawiki.org/wiki/Version_lifecycle), "The release manager has also 
issued a strong recommendation that versions not listed above as current 
version or legacy version should not be used in a productive environment. They 
may contain critical security vulnerabilities and other major bugs, including 
the threat of possible data loss and/or corruption". For example, wikiHow is 
running MediaWiki 1.12.0, which was released on 21 March 2008 -- over three 
years