Because of a surge of interest in recent times, we have started a mail list
for QA activities connected with WMF projects. If this interests you, feel
free to sign up at https://lists.wikimedia.org/mailman/listinfo/qa. The
list is completely open, so also feel free to mention it to anyone else for
whom this sort of discussion might be of interest.
Below is a sample of the sort of things we will discuss on the QA list:
OPW:
Congratulations Rachel Thomas (rachel99) on being selected to work on
browser test automation with us as part of the Gnome FOSS Outreach Program
for Women. Rachel has been a volunteer for some time now and despite
starting from scratch with gerrit and Ruby/Cucumber/PageObject has already
made valuable contributions to the browser tests. We're really looking
forward to working with Rachel over the summer.
Amsterdam Hackathon:
While Željko and Chris have met any number of times before, this was our
first meeting outside of the USA. Together we cleaned up many failing
builds at https://wmf.ci.cloudbees.com/; we implemented some tests for the
Universal Language Selector; and we gave a presentation on the current
state of the browser tests to a number of interested (and interesting!)
people.
In the course of making the builds green, we:
* updated the Guided Tour test to reflect the latest behavior of that
feature
* repaired a bogus error message from parallel_cucumber causing false build
failure reports
* adjusted the target test environments among beta labs enwiki and commons,
test2wiki, and production to yield optimum coverage with a minimum of red
builds.
We also extended some test coverage:
* checked in a test for Appearances and Datetime Preferences
* checked in an interim fix for sidebar expand/collapse tests while we
explore setting cookies in IE
* wrote a new test for Universal Language Selector based on some work from
Runa Bhattacharjee of the Language team, and planned for more ULS tests
very soon. (Fixing
https://bugzilla.wikimedia.org/show_bug.cgi?id=45958will be helpful)
In the very near future we'll be working with tests for VisualEditor as
well, which continues to have some interesting bugs:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48166. Bug 48166 and a few
others were identified as part of a community test exercise at the Telerik
Test Summit peer confernence in Austin TX not long ago.
We are also looking forward to using YuviPanda's new github-gerrit
integration.
Again, we extend an invitation to anyone interested in testing, test
automation, and QA activities in general to join the mail list at
https://lists.wikimedia.org/mailman/listinfo/qa
-Chris McMahon
QA Lead for WMF
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm happy to announce the availability of the first stable release
of the new MediaWiki 1.21 release series.
MediaWiki 1.21 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.21 file for the full list of changes
in this version.
Our thanks go to everyone who helped to improve MediaWiki by testing
the beta release and submitting bug reports.
== What's new? ==
MediaWiki 1.21 includes all changes released in the smaller, bi-weekly
"1.21wmfX" software deployments to Wikimedia sites.
=== Clearer email notifications ===
Bug 14901 ? Email notification mistakes log action for new page
creation, the third most reported open MediaWiki bug, has been
fixed. Consequently, notifications now state clearly what action was
performed on the watched pages in case they are created, deleted,
restored, moved or changed.
There are still some known issues. If you customised MediaWiki:Enotif
body on your wiki, you have to delete or update it; see also full
documentation.
=== Skin ===
The CologneBlue skin has been refactored to make it relevant again,
more compatible with existing scripts, and more similar in structure
to Vector and Monobook, reusing a lot of existing code.
The only major difference for end-users should be a slight reordering
of the sidebar menu (the "Context" submenu was removed and its
contents merged into other ones). If you were, however, depending on
the exact HTML it used to produce, you'll need to review your tools.
=== ContentHandler ===
As part of the Wikidata initiative, 1.21 adopts an extensible
framework ("ContentHandler") so that pages can contain something other
than wikitext.
Right now, built-in content types are limited to
wikitext - wikitext, as usual
javascript - user-provided JavaScript code
css - user-provided CSS code
text - plain text
Extension developers can create additional content
types. Extension:EventLogging uses ContentHandler to implement a
namespace for JSON schemas, and may be used as a reference. Other
extensions, such as Scribunto, also make use of the new functionality.
ContentHandler affects diff rendering, handing of CSS and JavaScript
pages, import/export, and the API.
=== Support for high DPI displays ===
MediaWiki now tries to deliver higher-res images to high pixel density
screens such as Apple Retina Displays (see gerrit change 24115 for
details). This is a work-in-progress, so normal-resolution images may
still appear in some places and in some browser
versions. Administrators may need to watch out for higher load on
their image scaling software.
=== Ajax patrolling ===
(bug 7851) The features users have waited for longest: one-click Ajax
patrolling. With this new feature, users can mark revisions or pages
as having been "patrolled" with a single click while staying on the
current page.
=== Internationalization ===
(bug 24156) The general logging framework was made completely
localisable at last. The logging for each action (whether in core or
extensions) might still need to be updated to use the new system,
though.
(bug 40367) MediaWiki:Contributions now reflects the gender of the
user.
=== New accounts ===
(bug 22457) It's now easier to create accounts for other users by
sending a temporary password via e-mail: Special:CreateAccount now
shows a checkbox for logged-in users to use this feature, rather than
a button.
Account API: bots and other scripts can now use the API to create user
accounts, rather than attempting to pseudo-submit the HTML form.
=== Account creation welcome ===
The MediaWiki:welcomecreation message was split up into
MediaWiki:welcomeuser and MediaWiki:welcomecreation-msg so users no
longer see "Login successful" when creating their accounts (bug
42215). If you customized the former message and want to preserve your
customization, you'll have to modify the new messages accordingly.
=== More wikitext now supported in JavaScript messages ===
The jqueryMsg parser now supports wikilinks and int: transclusion. For
more details, see Manual:Messages API.
=== Using semantic headings for the navigation menu ===
The previous scheme of using (varying per skin) <h4>, <h5> and/or <h6>
tags (with nothing apart from the main <h1> above them in the
hierarchy) was change to consistently using a <h2> above the entire
navigation and <h3>s as portlet headings in all skins.
The <h2> is hidden for normal browsers, but accessible for
screen-readers or text browsers.
While this change is minor, it might require similarly minor updates
in any customized CSS or JS (or in screen scrapers).
=== Extended collation support ===
UCA-based category collations for 68 languages based in Latin, Greek
and Cyrillic alphabets are now supported. You can use them by setting
$wgCategoryCollation = 'uca-<langcode>', where <langcode> is the
appropriate language code.
=== Bundled extensions ===
Newly bundled for 1.21 (bug 43815):
Cite
ImageMap
Interwiki
Title Blacklist
SpamBlacklist
Poem
InputBox
LocalisationUpdate
SyntaxHighlight GeSHi
Full release notes:
https://www.mediawiki.org/wiki/Release_notes/1.21
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.21/mediawiki-1.21.0.tar.gz
Patch to previous version (1.20.0), without interface text:
http://download.wikimedia.org/mediawiki/1.21/mediawiki-1.21.0.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.21/mediawiki-i18n-1.21.0.patch.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.21/mediawiki-core-1.21.0.tar.gz.s…http://download.wikimedia.org/mediawiki/1.21/mediawiki-1.21.0.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.21/mediawiki-1.21.0.patch.gz.sighttp://download.wikimedia.org/mediawiki/1.21/mediawiki-i18n-1.21.0.patch.gz…
Public keys:
https://secure.wikimedia.org/keys.html
- --
http://hexmode.com/
Imagination does not breed insanity. Exactly what does breed insanity
is reason. Poets do not go mad; but chess-players do.
-- G.K. Chesterson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iD8DBQFRoNaqc17xCi38v/URAgClAJ9YnIT5CLqfbFolRyoG8W7UOF+l6QCfSu5H
p79h+WXqEqs9MgYl1t+ES94=
=shHJ
-----END PGP SIGNATURE-----
Hi.
I noticed today that <http://status.wikimedia.org/> loads Google Analytics:
---
document.write(unescape("%3Cscript src='" + gaJsHost +
"google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
$(document).ready(function(){try{pageTracker =
_gat._getTracker("UA-230951-5"); pageTracker._trackPageview();}catch(err){}
});
---
Who manages this Google Analytics account? Is Google Analytics used on any
other Wikimedia domains?
MZMcBride
What: Internationalization bug triage
Date: May 29, 2013
Time: 1700-1800 UTC, 1000-1100 PDT (Timezone conversion: http://hexm.de/r0)
Channel: #mediawiki-i18n (Freenode)
Etherpad: http://etherpad.wikimedia.org/BugTriage-i18n-2013-05
Questions can be sent to: runa at wikimedia dot org
Hello,
The Language Engineering team would like to invite everyone for the
upcoming bug triage session on Wednesday, May 29, 2013 at 1700 UTC
(1000 PDT). During this 1 hour session we will be using the etherpad
listed above to collaborate. We have already listed some bugs, but
please feel free to add more bugs, comments and any other related
issues that you’d like to see addressed during the session. You can
send questions directly to me on email or IRC (nick: arrbee). Please
see above for event details.
Thank you.
regards
Runa
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
RE: https://www.mediawiki.org/wiki/Extension:AJAXPoll
Today, I published a new version of the AJAXPoll extension.
Most important change:
poll results are only shown for users who have voted.
Can be configured (deactivated) per-wiki, and also per-poll (see manual).
A database schema change is needed: run php update.php .
Have fun with it.
Hey Keith,
This is more a topic for the people that work or have worked on the
resource loader, and thus better suited for the wikitech-l mailing list,
which I have now cc'd.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
On 26 May 2013 14:48, Keith <whyteks(a)gmail.com> wrote:
> I am developing D3JS reports.
>
> Using:
> SemanticResultFormats 1.9 alpha
> SemanticMediaWiki 1.9 alpha
> MediaWiki 1.19.6
>
> I was developing with
> $wgResourceLoaderDebug = true;
> in LocalSettings.php and discovered that things broke when I turned that
> off.
>
> Iron gave me this error:
>
> Uncaught SyntaxError: Unexpected token ) load.php:62
> <
> http://qqw/load.php?debug=false&lang=en-gb&modules=ext.cite%2Crtlcite%7Cext…
> >
>
> and Firefox:
>
> Error: SyntaxError: function statement requires a name
> Line: 62, Column: 8
> Source Code:
> function(x){var j=d3.bisect(domain,x,1,k)-1;return i[j](u[j](x));};}
>
> I tracked it down to line 2436 in resources/jquery/d3/d3.v3.js -
> Version 3.0.4 is bundled with SRF 1.9a
>
> while (++j <= k) {
> u.push(uninterpolate(domain[j - 1], domain[j]));
> i.push(interpolate(range[j - 1], range[j]));
> }
> return*<load.php is line breaking HERE>* function(x) {
> var j = d3.bisect(domain, x, 1, k) - 1;
> return i[j](u[j](x));
> };
>
> Now, the d3.js code reads ok to me, so I assume it is some unfortunate
> coincidence that just happens to line break right there where it should
> not.
>
> I first added a throwaway line at 2436 (foo=bar;) and that fixes it.
> Then I replaced d3.js with version 3.1.8 of and that is also OK.
> Also, of course, leaving $wgResourceLoaderDebug = true; in
> LocalSettings.php is a work around.
>
> So, this is just a heads up that something is broken in that load.php
> minifying code. I haven't looked at it at all. I'm just prototyping
> stuff for D3JS and SMW/SRF at the moment. I'm really "doing my own
> thing" but after I get my required functionality I might look at
> mediawiki-ifying my code. I currently have some forced-directed graphs
> working from Special:Ask.
>
> I notice that the problem does not occur with any of the other D3 graphs
> that are implemented in SRF.
> I took a quick look at the output of load.php with these resources and
> effectively, that line break is not occuring in the sameplace.
>
> I can't figure out what is causing the problem.
>
>
> Keith.
>
> _______________________________________________
> Semediawiki-user mailing list
> Semediawiki-user(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>
For those of you not at the hackathon, there is one very major result
from the meeting that I wanted to publicize. (There are other action
items which I'll let other people expand but this one seems most
important to me.) If I misunderstood or mis-state something, Robla and
others can correct me.
Our RFC process has been broken till now. WMF's architecture group has
just committed to review and respond to all RFCs by WikiMania. This
will probably involve clarifying the process that RFCs are reviewed and
providing better documentation for architectural and design direction.
I expect there will be more coming out of this meeting, but I wanted to
post this note so I would remember to ask Brion about the RFCs he has
reviewed next Friday.
Mark.
--
http://hexmode.com/
Imagination does not breed insanity. Exactly what does breed insanity
is reason. Poets do not go mad; but chess-players do.
-- G.K. Chesterson
Hi folks,
Many of us met at the Amsterdam Hackathon to discuss architecture
guidelines (almost everyone with +2 in MediaWiki core, plus other
knowledgeable people), and generally about the need to have more
substantive conversations about MediaWiki architecture. It was a
really productive discussion, and had a number of outcomes:
1. RFC review: we agreed that RFCs need more diligent review. Brion
and Tim are planning to pull together the architects for regular
discussions (weekly? TBD) to at least touch all of the outstanding
RFCs, with the goal of clearing the current backlog of RFCs. If y'all
don't see substantial movement on this in a couple of weeks, please
point this out.
2. RFC use: right now, RFCs aren't used in many cases where they
should be. Assuming we get into a good flow with RFCs, we can then
reasonably expect people to actually write them when they're making
significant changes to the MediaWiki architecture.
3. Architecture guidelines: we now have a rough beginning draft of
architecture guidelines[2] we plan to use as guiding principles for
RFC review. This is a document that we plan to discuss on wiki in c2
wiki style[3]. Please participate! This is a living document, which
will be referenced in RFCs and responses to RFCs. We will use this
mailing list to discuss the more contentious issues and generally
ensure we continue to move forward refining this document.
4. A general agreement that we need to make sure that we have similar
conversations at every substantial gathering of +2 developers. For
example, we plan to figure something out for Wikimania.
We have raw notes from both days of meetings, available here:
https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013/Architectural_princ…
Rob
[1] http://www.mediawiki.org/wiki/Requests_for_comment
[2] https://www.mediawiki.org/wiki/Architecture_guidelines
[3] "c2 wiki style" is with inline comments similar to the c2 Design
Patterns wiki: http://c2.com/cgi/wiki?DesignPatterns