Helder Geovane kindly asked me to post this here, after I published a comment at
http://meta.wikimedia.org/wiki/Talk:SVG_image_support#Batik_server_revisited
This started out when a colleague posted a proposal on strategy wiki of throwing
some foundation money at the active development of rsvg. I wanted to counter
this with an old question: why not use Batik instead? The decision for rsvg in
2006 was based on the asumption that a Java application was a bad idea due to
overhead. At this time, a user proposed a http Server app based on Simple
(http://www.simplframework.org). He published a demonstration version
(http://batikd.sourceforge.net/), but noone reacted, and his work stopped. Now I
have taken a look at his approach, and I find the results are not that bad, for
an early development stage: in most cases, the batikd rendering times are two or
three times those of rsvg, and in some specialized cases (extensive use of
filters), batikd is even faster.
I would say, like rsvg improvements, a Batik server for a production environment
would need considerable work, and I am frankly not qualified to do it. So,
regarding the funding proposal my position is to say that there are multiple
avenues to get better SVG support. (I have seen the comments about svgweb,
another project that seems to need work before it is usable.)
This post here is only meant as an encouragement if someone who knows more about
server development than I do would like to take a deeper look.
A fundamental principle of medicine is "do no harm." It has a long history and you can find it in the Hippocratic oath with a slightly different wording.
This is also an important principle of software development. If you add a new feature or fix a bug, make sure the resulting code isn't worse off than before. Do no harm is the basic motivation behind regression testing.
I have been thinking about Brion's suggestion of fixing the bug in WebRequest::extractTitle(). It is a reasonable point. Don't just whine about a problem. Fix it. He even provided the best strategy for accomplishing this. Make "sure $wgScriptPath gets properly escaped when initialized." I am sure doing this would not require a significant amount of coding. But, how would changing the way $wgScriptPath is formatted affect the rest of the code base?
I decided to do a multi-file search for $wgScriptPath in phase3 and extensions [r53650]. There are 439 references to it in phase3 and extensions combined. In phase3 alone, there are 47 references. Roughly 1/3 of these are in global declarations, so phase3 has about 30 "active" references and in phase3 and extensions combined there are roughly 300. [By "active" I mean references in which the value of $wgScriptPath affects the code's logic.]
So, if I were to change the formatting of $wgScriptPath, there potentially are 30 places in the main code and 300 places in extensions where problems might occur. To ensure the change does no harm, I would have to observe the effect of the change on at least 30 and up to 330 places in the distribution. This is pretty onerous requirement. My guess is very few developers would take the time to do it.
On the other hand, if there were regression tests for the main code and for the most important extensions, I could make the change, run the regression tests and see if any break. If some do, I could focus my attention on those problems. I would not have to find every place the global is referenced and see if the change adversely affects the logic.
Chad <innocentkiller(a)gmail.com> wrote:
> DumpHTML will not be moved back to maintenance in the repo, it was
> already removed from maintenance and made into an extension. Issues
> with it as an extension should be fixed, but it should not be encouraged
> to go back into core.
What I meant was I can move the code in DumpHTML as CPRT to maintanence in my working copy and work on it there. Whether this code is simply a MacGyver test or something else is completely up in the air.
> Also, on a meta note....can you possibly confine all of your testing comments
> to a single thread? We don't need a new thread for each problem you find :)
>
My apologies.
Dan
Are there any license requirements for extensions checked into wikimedia's
SVN? I am taking over maintanance of an OpenSSO authentication extension
from Sun, and it is currently CDDL licensed.
Does it need to be GPL, or is CDDL an acceptable license?
V/r,
Ryan Lane
I have been playing around with phpunit, in particular its facility for generating tests from existing PHP code. You do this by processing a suitably annotated (using /* @assert ... */ comment lines) version of the file with phpunit --skeleton. Unfortunately, the --skeleton option assumes the file contains a class with the same name as the file.
For example, I tried annotating Hook.php and then processing it with phpunit --skeleton. It didn't work. phpunit reported:
Could not find class "Hook" in ".../phase3/tests/Hook.php"
(where I have replaced my path to MW with "...").
Since there are many MW files that do not contain classes of the same name as the file (or even classes at all), the --skeleton is probably not very useful for MW phpunit test generation.
You can still use phpunit by inserting the appropriate test code manually, but the objective of automatically generating tests with the same convenience as adding lines to parserTests.txt isn't available.
Dan
Dear MediaWiki developer,
within the scope of my diploma thesis at the University of Paderborn, Germany, with the title "Study about communication and collaboration in software development in teams" I am conducting a survey of members of software development teams.
I would be very grateful if you help me in my studies and answer the survey at http://thales.cs.upb.de/limesurvey185/index.php?lang=en&sid=91192&token=u52…
This is the official description of the survey:
In the last years many means of communication and collaboration were introduced in software projects to assist the development teams with their daily work.
With this study we want to identify requirements for a communication- and collaboration-supporting platform for software development. For this purpose we will evaluate the utilization and effectiveness of different means of communication and collaboration in solving software and managerial problems in software development teams.
The survey will take about 10-15 minutes and contains 55 questions that cover various topics.
Many thanks for your support of my research. If there are any further questions, don't hesitate to contact me.
Best regards from Paderborn, Germany
Martin Gelhaus (gelhaus(a)upb.de)
----------------------------------------------
Click here to do the survey:
http://thales.cs.upb.de/limesurvey185/index.php?lang=en&sid=91192&token=u52…
----
Martin Gelhaus
Graduand at Didactics of Informatics chair at University of Paderborn
Fürstenallee 11
Room F2.416
D-33102 Paderborn
Since I have run out of ideas of where to nag devs with shell access
(bugzilla is completely ignored most of the time, and mail/irc didn't
have much effect either), I'll try here.
The following are all one-line configuration changes:
Bug 14716 – Grant noratelimit right to the editor group in the
Hungarian Wikipedia (open for over a year)
Bug 19109 – Enable AbuseFilter in Hungarian Wikipedia (open for two months)
Bug 19315 – Set $wgCategoryPrefixedDefaultSortkey=false on Hungarian
Wikipedia (open for one and half month)
Bug 19885 – Restore autoreview for confirmed usergroup on huwiki
(severity:major, open for 10 days)
It would be really nice if someone could finally take a look at these,
especially the last one which completely sabotages the use of FlagRev
on huwiki (and which resulted from careless sysadmin action in the
first place).
More generally, I think the procedure for responding to site requests
(if there is a procedure at all) needs fixing. My impression is that
some requests are resolved quickly, and the rest leave the range of
whatever method shell people use to monitor new requests, and are
never picked up again (much like recent changes patroling on the
wiki). Some sort of backlog of open site requests might help the
situation. (Again, these are one-liners that need neither much thought
nor much effort, nor are they terribly frequent - there were 3 site
requests alltogether this year for huwiki, which is a top20 wikipedia
- so I'm sure it's an attention problem, not a resource problem.)
convenience links:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14716https://bugzilla.wikimedia.org/show_bug.cgi?id=19109https://bugzilla.wikimedia.org/show_bug.cgi?id=19315https://bugzilla.wikimedia.org/show_bug.cgi?id=19885