While I would not list the Mediawiki language as a 'crap' language,
I still think it is regretful that one cannot achieve the precision of
an HTML <a name="bla"> anchor, to say, make a link to a spot anywhere
within a page, whereas with the Mediawiki language, the best one can do
is link to the top of a table for example,
http://en.wikipedia.org/wiki/Historical_Chinese_phonology#Initials
instead of also to a random point within say, giant tables.
This week, Sumana said she had some people who were interested in
looking at old bugs to see if they were still reproducible under 1.17.
I decided to steal this idea for a great weekend sprint that even people
who are not developers could take part in: Help me look at these bug
reports and see if the problems they describe are still reproducible or
if the problem has been fixed.
If you don't have a test wiki with 1.17 installed, then you can try to
reproduce a lot of these on Wikipedia in your user sandbox. If you
don't have one yet, you can use this link to load one: http://hexm.de/4w
If you come across one that you don't know how to reproduce in your user
sandbox or on your own wiki, then add the keyword “testme”.
With that out of the way, there are plenty of bugs to test. Here are a
few ways to find a good candidate for testing:
* There are currently 616 bugs that are explicitly filed against pre-1.17
versions of MediaWiki: http://hexm.de/4e
* If you modify the query to remove those bugs labeled “enhancement”,
you'll end up with 345 bugs: http://hexm.de/4j
* Some bugs just have “unspecified” as the version. There are 1747 MW
that were created before 2011-06-22 (1.17's release date) with
“unspecified” as the version number: http://hexm.de/4f
* Again, if you remove the ones labeled “enhancement”, you come up with
526 bugs: http://hexm.de/4g
You can do all sorts of things to reduce the list to nice bite-sized
chunks. Here, for example are smaller lists of bugs marked “normal” or
higher severity for each version of MW in bugzilla:
1.6.x (11 bugs)
http://hexm.de/4k
1.7.x (5 bugs)
http://hexm.de/4l
1.8.x (3 bugs)
http://hexm.de/4m
1.9.x (14 bugs)
http://hexm.de/4n
1.10.x (17 bugs)
http://hexm.de/4o
1.11.x (23 bugs)
http://hexm.de/4p
1.12.x (20 bugs)
http://hexm.de/4q
1.13.x (21 bugs)
http://hexm.de/4r
1.14.x (26 bugs)
http://hexm.de/4s
1.15.x (42 bugs)
http://hexm.de/4t
All 1.16 versions (94 bugs)
http://hexm.de/4v
I'm fascinated by the jump from 26 bugs version 1.14 to 42 bugs in
version 1.15 and then the big bounce to 94 bugs in 1.16 and think this
is a good area to dig into. I'm interested in *why* that is there,
whether it is because of more people checking, better reporting, or
(hopefully not) worse solving.
Of course, we still need people to look at the “testme” bugs, too:
http://hexm.de/4i
Finally, if you have followed the steps in the bug and can't reproduce
it, please mark it “FIXED”.
Comments are always helpful on the bugs, so leave one if you have a
question or comment about the bug.
Happy Testing!
Mark.
Hi folks,
this is a heads-up that Tomasz, Rob, Alolita, CT, Brion, Roan[TBC],
Howie and I will be meeting with ThoughtWorks (
http://en.wikipedia.org/wiki/ThoughtWorks ) Thursday and Friday. Rob
and I also got a download from Tim ahead of time.
ThoughtWorks has done great work with the fundraising developers
(Arthur, Katie, Kaldari) already in helping protect that team from
distractions, prioritize its work, and ensure that
roles/responsibilities are clearly understood vis-a-vis the
fundraising folks in the community department. So, we're now exploring
a deeper engagement with ThoughtWorks on problem-solving across the
engineering organization.
Following initial conversations, the purpose of the meeting tomorrow
is to do a deep-dive into a specific problem set: the code review,
deployment and release management process. We'll be digging into
questions like:
1) What are the best methods to ensure we keep up with the backlog
while still maintaining a good clip of WMF priority development;
2) What's a realistic deployment and release cycle to shoot for (for
trunk, extensions, branches);
3) How do we dissipate key skills more widely among both staff and
volunteers (e.g. deployment, security reviews);
4) How/when can we split "big hairy projects" with integration issues
into more manageable chunks;
5) What other high priority improvements do we need to prioritize
(e.g. increased test coverage, improvements to the testing frameworks,
het-deploy, staging environments, etc.)
We're intentionally keeping this first meeting at a manageable size to
have a high face-to-face throughput and to explore where ThoughtWorks
can best help us. But I'm very much intending to make our thinking
public, and to form clear and visible groups around core problems
we're tackling, just as we have been doing with all WMF engineering
projects. So, I'll keep you posted, and if you have thoughts that
you'd like to post ahead of time, please do it onlist or offlist :-)
Thanks,
Erik
--
Erik Möller
Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Hi,
is there any metric defined to see how the bug solving pro-
cess has improved over time?
The main reason I'm asking is today's two mails regarding
bug #24000 ("Update rsvg so styling SVG images with CSS
works properly on Commons"). Reported more than a year ago,
the solution found early on was to update rsvg. I would have
suspected that to do that you execute an "rpm -Uvh" equiva-
lent on the server farm and close the bug. Yet for months
nothing happened at all, and then some keywords were added,
removed and replaced.
From an outside perspective, this looks like (much) more
energy is spent on managing the bugs than actually squashing
them. But that of course is not only an outside perspective,
but the biased view of a user who is affected by the bug,
sees a possible solution on his screen and experiences the
helplessness of being at the mercy of someone else :-). So
is there any "scorecard" with more detailed data than the
weekly report, i. e. minimum/average/maximum time to closure
of bugs/non-bugs, some nice visualizations, etc.?
TIA,
Tim
Hi Sumana,
Sure I would be interestd in writing tests with other tools. I like the
record and play option in Selenium IDE to get a feel for the code. I am
seeing that TestSwarm is a possible tool that the developers are using. Is
there a tool with more of a record and play option, that will not interfere
with the pages, to use and become familiar with the code? Feel free to email
me offline too.
Michelle Knight
------------------------------
Message: 4
Date: Thu, 7 Jul 2011 11:23:30 -0400
From: Sumana Harihareswara <sumanah(a)wikimedia.org>
Subject: Re: [Wikitech-l] [Selenium] IDE test for regressing bug
https://bugzilla.wikimedia.org/show_bug.cgi?id=29310
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>,
mknight1130(a)gmail.com
Message-ID:
<CAJwy5OXpNu1uC=5=vGz7kzdCbP2zLY5eYNuGFHCKViXmk5XaWA(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Michelle:
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:
http://www.mediawiki.org/wiki/Requests_for_comment/Unit_testinghttp://www.mediawiki.org/wiki/Test_framework_deployment#Status:_Permanent_h…http://www.mediawiki.org/wiki/Selenium_Framework#Selenium.27s_uses_.26_flaws
Would you be interested in writing test suites or tests for some of these
other tools?
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
On Thu, Jul 7, 2011 at 11:23 AM, Sumana Harihareswara
<sumanah(a)wikimedia.org> 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?
-Chad
On Thu, Jul 7, 2011 at 12:29 AM, Alolita Sharma <asharma(a)wikimedia.org> wrote:
> Ian's been a software developer for about 15 years. He's worked on
> projects like the first open-source web framework, a billing system
> for a regional ISP, a custom video transcoding system, and a
> sensor-based flamethrower controller.
This reflects a change in our requirements for new hires, in response
to the Board resolution on openness, which requires us to "work with
colleagues to develop practices to discourage disruptive and hostile
behavior, and repel trolls and stalkers." If you don't know how to
operate a flamethrower ...
j/k -- welcome, Ian! Great to have you on-board :-)
--
Erik Möller
Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Hi,
in release notes of mw 1.16.4 the following was suggested:
It is necessary to upgrade MediaWiki to avoid an XSS vulnerability for
Internet Explorer clients, version 6 and earlier. Also, if you used
the Apache configuration I suggested in the previous release
announcement, you should update it to:
RewriteEngine On
RewriteCond %{QUERY_STRING} \.[a-z0-9]{1,4}(#|\?|$) [nocase]
RewriteRule . - [forbidden]
Is this still suggested in the latest version? I have several problems with file upload, when the option is enabled...
Best regards,
Johannes Weberhofer
--
Johannes Weberhofer
Weberhofer GmbH, Austria, Vienna