[MediaWiki-CodeReview] [MediaWiki r114896]: Revision status changed
"Nikerabbit" changed the status of MediaWiki.r114896 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114896 Old status: new New status: ok Commit summary for MediaWiki.r114896: adding missing newline ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r114892]: Revision status changed
"Nikerabbit" changed the status of MediaWiki.r114892 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114892 Old status: new New status: ok Commit summary for MediaWiki.r114892: s/gerrit approve/gerrit review/ ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r114891]: Revision status changed
"Nikerabbit" changed the status of MediaWiki.r114891 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114891 Old status: new New status: ok Commit summary for MediaWiki.r114891: Set svn:keywords property to Id ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Wikimedia skins directory
K. Peachey wrote: > 1.18 shouldn't be failing anymore since reedy put a symlink in place for it. > > Ideally people would code things like that (aka stuff that isn't > actually MediaWiki) shouldn't be doing it to be dependant on MW skin > folders, eg: build their own css files, Because like this is pointing > out, things can change (not just directories, but the actual files as > well). Hello, I would really love having a very basic set of HTML templates with some nice CSS that would let us instantly have the look'n feel of Vector without having to rely on such linking. We have several website that could uses it: http://noc.wikimedia.org/ http://noc.wikimedia.org/conf/ http://dumps.wikimedia.org/ and children https://integration.mediawiki.org/ https://svn.wikimedia.org/ Planet could use a refresh: http://en.planet.wikimedia.org/ What I would really love is a theme for the Twitter bootstrap system and have all of that placed in a git repo. We could then have the site above to use a snapshot of the theme and have a similar look'n feel all around. If there is any volunteer willing to do that, I will definitely use some personal time to review the code / css / puppet config. Our WordPress skin looks fine to me. But some other apps could use an update: ViewVC https://svn.wikimedia.org/viewvc Nagios http://nagios.wikimedia.org/ Doxygen output http://svn.wikimedia.org/doc/ Customizing them will be a bit more tedious though. -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia skins directory
1.18 shouldn't be failing anymore since reedy put a symlink in place for it.
Ideally people would code things like that (aka stuff that isn't
actually MediaWiki) shouldn't be doing it to be dependant on MW skin
folders, eg: build their own css files, Because like this is pointing
out, things can change (not just directories, but the actual files as
well).
I believe "//bits.wikimedia.org/skins/{monobook/main.css}" is setup to
always point to the latest version so that should be alright, but
someone else will need to confirm.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia skins directory
I don't think the problem is specific to the skins directory. Bits has been acting weird all day. To answer your question, I think either URL is fine. It just depends on if you want the CSS updated automatically or manually when new versions are deployed. If anyone knows otherwise, feel free to chime in. Ryan Kaldari On 4/16/12 8:08 PM, MZMcBride wrote: Hi. The URL for CSS used to be something like this: //bits.wikimedia.org/skins-1.18/monobook/main.css Now there's apparently this: //bits.wikimedia.org/skins-1.20wmf1/monobook/main.css But this also works: //bits.wikimedia.org/skins/monobook/main.css Can someone please explain which should be used? Unexpectedly getting rid of skins-1.18/ is actively breaking the look of certain pages (such as the www portals), but I'm not clear whether I should simply be switching to a new MediaWiki version in the URL or if there's something canonical I can use instead (which would obviously be preferred). I didn't see anything on the mailing list about this MZMcBride ___ 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] Wikimedia skins directory
Hi. The URL for CSS used to be something like this: //bits.wikimedia.org/skins-1.18/monobook/main.css Now there's apparently this: //bits.wikimedia.org/skins-1.20wmf1/monobook/main.css But this also works: //bits.wikimedia.org/skins/monobook/main.css Can someone please explain which should be used? Unexpectedly getting rid of skins-1.18/ is actively breaking the look of certain pages (such as the www portals), but I'm not clear whether I should simply be switching to a new MediaWiki version in the URL or if there's something canonical I can use instead (which would obviously be preferred). I didn't see anything on the mailing list about this MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [Wikimedia r1619]: New comment added
"Pgehres (WMF)" posted a comment on Wikimedia.r1619. URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1619#c32683 Commit summary for Wikimedia.r1619: UPDATE query was missing a WHERE statement. This is causing every record in `civicrm_contribution_recur` to get a new value set for `next_sched_contribution` whenever recurring_import_subscr_payment() is called. Pgehres (WMF)'s comment: This looks right, but will be difficult to test without some PayPal recurring coming in. We will just need to be on our toes right after the deployment. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] selenium browser testing proposal and prototype
On 16/04/12 16:45, Chris McMahon wrote: > Cucumber adds a layer of abstraction I think is unnecessary-- these tests > are to be read by developers, many of whom will not be expert. Rspec is a > nice alternative to xUnit-style assertions, and the standard among Ruby > developers. Which seem to be the only ones that will be able to write our tests. You can talk about how "there's a standard way" or "it's documented", but that doesn't help if they aren't easy to develop. For example X.509 is all standard you want, really flexible, but you wouldn't want to manually touch it :) Moreover, making tests is not generally fun to do, so you want the barrier to be as low as possible. > My idea right now is that maintaining the Selenium test suite as run by > Jenkins would be primarily a QA activity, with contributions from any other > interested parties in the greater community or among the > Mediawiki/Wikipedia dev/ops community. Contributions from developers would > be welcome but not required. Not that I have anything against making tests by opening bugs, and letting the QA team (who forms that?) struggle to make them work. It's simple to just be lazy and let you test it manually, with a monkey farm, gems or a street rat. But I don't think that's the way we should go. The developers should be able to maintain them, even if they're not daily involved with it. Not only for being able to keep them the day you stop doing it, but also for detecting why they fail and maintaining them when changing the expected output. It wouldn't be fun to held a discussion in gerrit about why a bunch of tests suddenly fail after merging a big feature, wondering what it could have been trying to test. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Patch for Widgets extension
It doesn't look like this extension is in Git. You should be able to commit to
it in Subversion.
Alex
On 16/04/12 21:25, Sergey Chernyshev wrote:
Guys,
I've updated Widgets extension to support latest version of
FlaggedRevisions, but no longer have repo access as MW moved to Git.
If somebody can patch the extension for me, I'll really appreciate that -
here's the diff (not much work):
Index: extensions/Widgets/WidgetRenderer.php
===
--- extensions/Widgets/WidgetRenderer.php (revision 114929)
+++ extensions/Widgets/WidgetRenderer.php (working copy)
@@ -137,7 +137,7 @@
if ( $widgetTitle&& $widgetTitle->exists() ) {
if ( $wgWidgetsUseFlaggedRevs ) {
- $flaggedWidgetArticle =
FlaggedArticle::getTitleInstance( $widgetTitle );
+ $flaggedWidgetArticle =
FlaggableWikiPage::getTitleInstance(
$widgetTitle );
$flaggedWidgetArticleRevision =
$flaggedWidgetArticle->getStableRev();
if ( $flaggedWidgetArticleRevision ) {
Thank you,
Sergey
--
Sergey Chernyshev
http://www.sergeychernyshev.com/
http://www.meetup.com/Web-Performance-NY/
http://www.showslow.com/
___
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] Patch for Widgets extension
Guys,
I've updated Widgets extension to support latest version of
FlaggedRevisions, but no longer have repo access as MW moved to Git.
If somebody can patch the extension for me, I'll really appreciate that -
here's the diff (not much work):
Index: extensions/Widgets/WidgetRenderer.php
===
--- extensions/Widgets/WidgetRenderer.php (revision 114929)
+++ extensions/Widgets/WidgetRenderer.php (working copy)
@@ -137,7 +137,7 @@
if ( $widgetTitle && $widgetTitle->exists() ) {
if ( $wgWidgetsUseFlaggedRevs ) {
- $flaggedWidgetArticle =
FlaggedArticle::getTitleInstance( $widgetTitle );
+ $flaggedWidgetArticle =
FlaggableWikiPage::getTitleInstance(
$widgetTitle );
$flaggedWidgetArticleRevision =
$flaggedWidgetArticle->getStableRev();
if ( $flaggedWidgetArticleRevision ) {
Thank you,
Sergey
--
Sergey Chernyshev
http://www.sergeychernyshev.com/
http://www.meetup.com/Web-Performance-NY/
http://www.showslow.com/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r114928]: New comment added
"^demon" posted a comment on MediaWiki.r114928. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114928#c32682 Commit summary for MediaWiki.r114928: Importing https://www.mediawiki.org/wiki/Extension:AkismetKlik/source Also bringing in https://github.com/achingbrain/php5-akismet/ Needs some love! ^demon's comment: Ugh, why ''why'' '''why''' would you create a new extension in Subversion that now has to have its history exported to Git when we can create a new repo in Gerrit in less than 10 minutes? No, don't bother deleting it now, it's too late. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] MathJax scalable math rendering update for 1.19
On Mon, Apr 16, 2012 at 12:26 PM, Erik Moeller wrote: > On Wed, Mar 7, 2012 at 1:05 PM, Brion Vibber wrote: > > In the last few days I've updated the Math extension's experimental > MathJax > > support to where it can actually be enabled by individual users. If all > > goes well with review I'd love to get this deployed soon so the > math-heads > > can turn it on and check for lingering incompatibilities... > > I notice that this has been deployed with 1.20wmf1 to wikis that have > it, but is disabled. Do you feel confident enough in the code at this > time that we could set $wgUseMathJax=true for mediawiki.org and invite > some more testing there? > I say we go for it -- what it'll do at this point is add a math rendering option so people can opt in to MathJax use, and actually test it in place. The more usage we get, the more feedback we'll get on things needing to be tweaked (there's some more commands that need to be added, and some tweaks for borders and things). -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MathJax scalable math rendering update for 1.19
On Wed, Mar 7, 2012 at 1:05 PM, Brion Vibber wrote: > In the last few days I've updated the Math extension's experimental MathJax > support to where it can actually be enabled by individual users. If all > goes well with review I'd love to get this deployed soon so the math-heads > can turn it on and check for lingering incompatibilities... I notice that this has been deployed with 1.20wmf1 to wikis that have it, but is disabled. Do you feel confident enough in the code at this time that we could set $wgUseMathJax=true for mediawiki.org and invite some more testing there? -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Unified login vs. unified settings
On 16/04/12 02:08, Andrew Garrett wrote: > *I* rewrote the preference system, and my proposed patch for global > preferences was part of that package. It was reverted, mostly to ease > review load. I think that's pretty much what I did when I implemented it (I > had a local flag to disable global preferences). Sorry, I didn't remember the details. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome, Chris Steipp
Welcome, I know you'll love it! 2012/4/16 Leslie Carr > Welcome! > > On Mon, Apr 16, 2012 at 10:32 AM, Sumana Harihareswara > wrote: > > On 04/16/2012 12:41 PM, Rob Lanphier wrote: > >> Hi everyone, > >> > >> I’d like to introduce Chris Steipp, who starts today as our Senior > >> Security Engineer. > > > > Looking forward to working with you, Chris. Welcome! > > > > -- > > Sumana Harihareswara > > Volunteer Development Coordinator > > Wikimedia Foundation > > > > ___ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > -- > Leslie Carr > Wikimedia Foundation > AS 14907, 43821 > http://as14907.peeringdb.com/ > > ___ > 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] Welcome, Chris Steipp
Welcome! On Mon, Apr 16, 2012 at 10:32 AM, Sumana Harihareswara wrote: > On 04/16/2012 12:41 PM, Rob Lanphier wrote: >> Hi everyone, >> >> I’d like to introduce Chris Steipp, who starts today as our Senior >> Security Engineer. > > Looking forward to working with you, Chris. Welcome! > > -- > Sumana Harihareswara > Volunteer Development Coordinator > Wikimedia Foundation > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [Wikimedia r1614]: Revision status changed
"Jpostlethwaite" changed the status of Wikimedia.r1614 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1614 Old status: new New status: ok Commit summary for Wikimedia.r1614: Cutting over the trunk version of the standalone globalcollect adapter to prod ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r1617]: Revision status changed
"Jpostlethwaite" changed the status of Wikimedia.r1617 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1617 Old status: new New status: ok Commit summary for Wikimedia.r1617: Adding a required file to the standalone adapter ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r1616]: Revision status changed
"Jpostlethwaite" changed the status of Wikimedia.r1616 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1616 Old status: new New status: ok Commit summary for Wikimedia.r1616: MFT r1615 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Welcome, Chris Steipp
On 04/16/2012 12:41 PM, Rob Lanphier wrote: > Hi everyone, > > I’d like to introduce Chris Steipp, who starts today as our Senior > Security Engineer. Looking forward to working with you, Chris. Welcome! -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [Wikimedia r1613]: Revision status changed
"Jpostlethwaite" changed the status of Wikimedia.r1613 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1613 Old status: new New status: ok Commit summary for Wikimedia.r1613: Creating the standalone GC adapter directory for deploy ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r1612]: Revision status changed
"Jpostlethwaite" changed the status of Wikimedia.r1612 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1612 Old status: new New status: ok Commit summary for Wikimedia.r1612: Creating the standalone directory for deploy ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r1611]: Revision status changed
"Jpostlethwaite" changed the status of Wikimedia.r1611 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1611 Old status: new New status: ok Commit summary for Wikimedia.r1611: MFT r1606, r1607 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r1610]: Revision status changed
"Jpostlethwaite" changed the status of Wikimedia.r1610 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1610 Old status: new New status: ok Commit summary for Wikimedia.r1610: MFT r1606, r1607 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] git-review wanting to submit lot of changes
I have run into that message before:
"You have more than one commit that you are about to submit."
If you do not want to commit, bust still will want to save revisions of
your work, then
get stash
is your friend.
If you need to know Git very well, then this is a very helpful list of
commands you need to know:
http://andyjeffries.co.uk/articles/25-tips-for-intermediate-git-users
Jeremy
On Sun, Apr 15, 2012 at 8:42 AM, Marcin Cieslak wrote:
> >> Daniel Friesen wrote:
> > What about the users who clone from their own GitHub fork as origin and
> > push side-project branches there before merging and pushing finished
> > projects to gerrit?
>
> A proper fix in the works currently is to not need .gitreview file at all
> if one of the remotes ("origin", "gerrit" or whatever) is pointing
> to a valid Gerrit instance. Actually we don't need a new remote at all;
> but that's the behaviour git-review insisted on.
>
> //Saper
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
--
Jeremy Postlethwaite
jpostlethwa...@wikimedia.org
415-839-6885 x6790
Backend Software Developer
Wikimedia Foundation
[MediaWiki-CodeReview] [MediaWiki r113415]: New comment added
"Saper" posted a comment on MediaWiki.r113415. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113415#c32681 Commit summary for MediaWiki.r113415: (bug 25095) Special:Categories doesn't show first relevant item when "from" is filled Saper's comment: Because not doing so causes bug 36019 :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Welcome, Chris Steipp
Hi everyone, I’d like to introduce Chris Steipp, who starts today as our Senior Security Engineer. Chris comes to us from Global Media Outreach, where he served as their CTO. Before that, he worked at Novacoast, doing security consulting. He went to school at Royal Hollaway in Egham, UK (just outside London). The Software Security Engineer was originally conceived as a means of increasing our code review capacity. One bottleneck in our code review process was when a specific security review was needed, because most people aren’t as confident in themselves to perform a specific review for security, nor confident in each other. That led to a situation where we had one person (Tim Starling) who would be the bottleneck for complicated security reviews. Now with Chris on board, we have someone (else) whose job it is to do security reviews. However, that won't be Chris's sole responsibility. A lot of Chris's time will be spent designing and developing new features and enhancing existing features of Wikimedia systems, with a particular focus on features requiring expertise in security (such as improved HTTPS support, better/different authentication features, and other handling of sensitive data). Chris is a friendly and enthusiastic teacher, and is planning to lead secure development training for the organization. Chris lives here in the SF Bay area with his (soon to be growing) family. Please join me in welcoming Chris! Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Unified login vs. unified settings
I'd love it too - but I noticed that different wikis have quite different settings due to different gadgets and extensions being available. So a good solution would have to be smart enough to accommodate this. Oren Bochman -Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Bináris Sent: Monday, April 16, 2012 7:44 AM To: Wikimedia developers Subject: Re: [Wikitech-l] Unified login vs. unified settings 2012/4/15 Ole Palnatoke Andersen > Hi! > > I would love to be able to manage my settings in one place There is somewhere a bot that does it for you, but I don't remember where I saw it. -- Bináris ___ 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
On Mon, Apr 16, 2012 at 5:14 AM, Gergő Tisza wrote: > > Not sure what counts as authoritative, but there are a number of fairly > usable > PHP implementations such as php-webdriver [1] from Facebook or > phpunit-selenium > [2] from the PHPUnit framework, both of which are non-complete but very > easy to > extend (and in practice, you don't use most Selenium commands anyway). I might disagree with both those assertions. Also, my (admittedly very superficial) experience with BDD is that > Cucumber/Gherkin is much better for acceptance testing than RSpec (which > is more > suited for unit testing). Cucumber adds a layer of abstraction I think is unnecessary-- these tests are to be read by developers, many of whom will not be expert. Rspec is a nice alternative to xUnit-style assertions, and the standard among Ruby developers. That said, if in the future some context were to come along where Cucumber makes sense, this framework allows adding that level of ATDD easily. > Mink has the additional advantage that it abstracts away the Selenium > interface > so that Selenium can be replaced with some other browser simulator without > changing the tests; while that doing Selenium-specific things more > complicated, > it can yield huge speedups for test which don't require Javascript and so > Selenium can be replaced with some simple browser emulator. The point of the exercise is to test browsers, not browser emulators. ___ 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
Chris McMahon wikimedia.org> writes: > 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: > > [...] > > ** 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. Not sure what counts as authoritative, but there are a number of fairly usable PHP implementations such as php-webdriver [1] from Facebook or phpunit-selenium [2] from the PHPUnit framework, both of which are non-complete but very easy to extend (and in practice, you don't use most Selenium commands anyway). Using one of them is more troublesome than choosing a language in which there is a reference Selenium implementation, but on the other hand, you don't need to introduce another language, you can write the tests in a language all MediaWiki developers are comfortable with, and you leave open the option of reusing MediaWiki components in tests to handle setup/teardown of fixtures in a clean way. Also, my (admittedly very superficial) experience with BDD is that Cucumber/Gherkin is much better for acceptance testing than RSpec (which is more suited for unit testing). Gherkin tests are clean, human-readable descriptions which are easier to read than program code, and can be easily understood by non- developers (end users, QA people, managers) even if they have no idea what a programming language is. On the other hand Gherkin is not a real programming language, so you lose some flexibility (such as the ability to use page objects), but IMO it is well worth it. And while RSpec relies on Ruby's elegant but obscure poetry mode, and thus cannot be easily copied in other languages, Gherkin has a simple custom syntax which is trivial to implement in any language; specifically, there is a good PHP implementation called Behat [3] which has its own Selenium implementation (Mink [4]) but also can be used with any other Selenium library. Mink has the additional advantage that it abstracts away the Selenium interface so that Selenium can be replaced with some other browser simulator without changing the tests; while that doing Selenium-specific things more complicated, it can yield huge speedups for test which don't require Javascript and so Selenium can be replaced with some simple browser emulator. (Yes, Selenium2 has its own browser emulator, but it is still a fair bit slower than something like Goutte [5]). So maybe a PHP - Mink (or other Selenium library) - Behat stack instead of a Ruby - Watir - RSpec stack would be worth considering. [1] https://github.com/facebook/php-webdriver [2] https://github.com/sebastianbergmann/phpunit-selenium [3] http://behat.org/ [4] http://mink.behat.org/ [5] https://github.com/fabpot/Goutte ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [pywikipedia r10115]: Revision status changed
"Xqt" changed the status of pywikipedia.r10115 to "ok" URL: http://www.mediawiki.org/wiki/Special:Code/pywikipedia/10115 Old status: new New status: ok Commit summary for pywikipedia.r10115: Localisation updates from http://translatewiki.net. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Too many random test wikis
I made [[mediawiki:Test_wikis]] feel free to improve it and link to that page from everywhere possible where people might be looking for this On Mon, Apr 16, 2012 at 1:51 AM, Federico Leva (Nemo) wrote: > Just in case someone thinks otherwise, none of my doubts has been addressed. > The point is what Helder stressed, and a lot of work is needed to reduce > confusion. > > Nemo > > > ___ > 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
