Hi everyone,
Just repeating something I just posted to
http://techblog.wikimedia.org/2011/02/planned-1-17-deployment/
The engineering team is busy working on the deployment of the 1.17 branch of
MediaWiki[1]. We plan to roll this out next week to all languages and
projects, Tuesday, February 8, with work starting at 07:00 UTC (which is
11pm on Monday, February 7 for San Francisco).
If all goes well, you should only notice the improvement. If it doesn’t go
well, that’s because there’s something we missed, and that’s where we’d love
your help. Please help us test this release! We have a test instance of the
software we plan to deploy available at http://prototype.wikimedia.org/. If
you find issues, please report them in Bugzilla:
http://www.mediawiki.org/wiki/Bugzilla
There are many, many little fixes and improvements that have gone into 1.17
(see the draft release notes[2] for an exhaustive list) . There isn’t much
that’s visible to users of the site, but one under the hood improvement that
should result in some speed improvements: Resource Loader[3]. Resource
Loader optimizes the use of JavaScript in MediaWiki, speeding up delivery of
JavaScript by compressing it sometimes, and cutting down on the amount of
unused JavaScript that gets delivered to the browser in the first place.
Much of the work in this development cycle has been centered on ensuring
compatibility with the new system. Since it makes such a large shift in the
way that JavaScript is delivered to the browser, it’s also an operational
aspect we’ll be keeping a close eye on, as load shifts between servers in
our infrastructure.
Note that this isn’t a release for download, yet. On and after February 8,
the “latest” version of MediaWiki will still be 1.16 as listed on
mediawiki.org. We plan to update this to 1.17 sometime after the deployment
of the 1.17 branch, after we’ve had time to run it in production for a while
and fix the issues we’re likely to find.
So please, help us test this release, and if you find bugs, please report
them in Bugzilla. Thanks!
Rob
[1] http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17
[2]
http://svn.wikimedia.org/viewvc/mediawiki/branches/REL1_17/phase3/RELEASE-N…
[3] http://www.mediawiki.org/wiki/ResourceLoader
[4] http://www.mediawiki.org/wiki/Download
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)
Yeah, all you need to do is remove the incorrect links from all affected
articles.
You sorta did that with -localright. however that just fixed the correct
article but still left some articles pointing to the wrong article. you need
to fix every article, as long as one page has the wrong link it will be
propagated back
On Wed, Feb 2, 2011 at 8:01 PM, Marcin Cieslak <saper(a)saper.info> wrote:
> (cross posted to wikitech-l)
>
> Hello,
>
> Recently we have found a case of incorrect interwiki entry linking
> [[:pl:Aktywizm]]
> describing philosophical concept with family of the articles on other
> Wikipedias
> regarding political activism.
>
> This was a human mistake and it was reverted later. However, there seems
> to be no way to tell all the interwiki bots running to stop re-adding this
> removed link to articles.
>
> I have added {{nobots}} on the Polish and English Wikipedia to prevent
> spreading of incorrect linking. I have tried from time to time to use
> my own pywikipedia bot to remove the link (using -localright option)
> and the result is the following:
>
> https://secure.wikimedia.org/wikipedia/ro/wiki/Activism?action=history
>
> (Saperka is my script)
>
> I spoke with the owner of WikitanvirBot and we have stopped it for
> a while completely to allow the "undo" script run and remove the links.
> Unfortunately, some other bot (
> https://secure.wikimedia.org/wikipedia/ro/w/index.php?title=Activism&diff=5…
> )
> changed the link again.
>
> It seems like it is not possible to revert one mistake unless
> ALL running interwiki bots will be stopped by their owners.
> Sounds like an overkill (and imagine coordinating this!).
>
> Is there some way interwiki.py could be improved (I know it should be
> all different architecture) or some other way to handle this
> - one could imagine - simple case?
>
> Or are we now overtaken by robots beyond our control? :)
>
> //Saper
>
>
> _______________________________________________
> Pywikipedia-l mailing list
> Pywikipedia-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
>
The first issue is indeed that the wrong interwiki has to be removed
on _all_ languages to stop it from returning, but even with that one
could still get into problems because there might be bots that visited
some languages _before_ your removal, and others _after_ it. They
would then consider the wrong interwiki to be a missing one on the
languages visited afterward, and re-add them there.
Working with {{nobots}} as you have done is not a good solution, I
think. Adding it on the Polish page could be justified, but on the
English one it also stops a good amount of correct edits.
This particular issue I have now resolved by finding that there is a
Dutch page on the same subject as the Polish one, and adding an
interwiki to that one. This way, even if someone mistakenly adds the
incorrect link again, for the bots this will lead to an interwiki
conflict, so they will not automatically propagate the wrong link any
more.
--
André Engels, andreengels(a)gmail.com
Hi, folks,
After two months of work, I just release the alpha version of wikiedge.orghttp://www.wikiedge.org/ An online magazine for Chinese Wikipedia
The basic idea of the website is to remix good content from Chinese
Wikipedia into a magazine style.
It is still in early phase, lots of bugs and big room to improve, but the
concept itself was proven.
The goal of the project is promote reachness of Wikipedia in Mainland China.
Though it is not a big project, but I still think it would be helpful.
It is an opensource project hosted at github
https://github.com/mountain/distilled
I invite developers here to join the project, but you'd better understand
Chinese.
If you want to port the idea into other languages, please contact me, and I
can also help you.
Thanks.
Regards,
Mingli (Mountain)
Hi everyone,
We're getting very close to deploying 1.17 to the Wikimedia Foundation
websites, but still have a fair amount of code (102 revisions) to
review and possibly revert. One big obstacle that could cause us to
get cold feet is the number of revisions marked "fixme" (29
revisions):
http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17/Revision_report#Fixmes
Here's the list of people that have open fixmes: bharris, catrope,
churchofemacs, dantman, demon, ialex, jeroendedauw, maxsem,
mgrabovsky, neilk, nikerabbit, nikola,
nimishg, platonides, purodha, raymond, thomasv, werdna, yaauie
If you're on that list, please take a look at the URL above, and at
least comment on your revisions. We really can't leave the fixmes out
there for much longer and expect to actually deploy 1.17 next week.
Thanks
Rob
Reminder that an open community meeting is proposed for this Saturday,
Feb. 5. on IRC: freednode#wikimedia
Please add your agenda items!
http://meta.wikimedia.org/wiki/Wikimedia_meetings
based on feedback I'd like to move the time down to 1800-1900 UTC
(that's 10 am PST).
Let me know if you can help moderate.
Looking forward to it,
Phoebe
On Tue, Jan 25, 2011 at 10:54 AM, phoebe ayers <phoebe.wiki(a)gmail.com> wrote:
> Hi all,
>
> Back in September we had an open community IRC meeting, where we
> introduced the new Trustees and talked about various issues. It was
> pretty successful and we discussed afterwards making such "community
> meetings" a regular event.
>
> I'd like to revive this idea :) I've made a proposal for having
> community meetings on the first Saturday of the month:
> http://meta.wikimedia.org/wiki/Wikimedia_meetings
>
> Which would make the first upcoming meeting on February 5.
>
> I proposed 17:00UTC as a time, but please discuss good days/times on
> the talk page if you are interested in attending; we'll need to rotate
> times.
>
> I envision this as not really a Q&A session like the staff office
> hours, but rather as a chance for community members to get together
> and talk about important issues in a structured way. To that end,
> please add your proposed agenda items to the wiki. It would also be
> great to have some volunteers to take notes/moderate.
>
> Of course this is just an experiment -- but there seemed to be a lot
> of interest in having such meetings, so I'd like to try it out. Let me
> know what you think and if you'd be interested.
>
> best,
> Phoebe
>
> --
> * I use this address for lists; send personal messages to phoebe.ayers
> <at> gmail.com *
>
This idea arose in the context of a discussion which generally addressed
civility. The warnings would be civility warnings.
Fred
> To that end, a warnings tool would be helpful,
> supplementing or replacing the uw- templates with a MediaWiki
> extension that requires that warnings be acknowledged by the editor to
> continue editing, and providing a record of warnings. This is
> basically a very soft block that the editor is free to remove
> themselves. Warnings need not be generally visible except in the case
> where a matter progresses to arbitration, but they should persist for
> a period of time so that patterns of behavior become apparent.
>
> -Stephanie
Brilliant!
Fred Bauder
For those of you who didn't see bug 26791, our use of JSMin has been
found to conflict with our GPL license. After assessing other options (
https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I
decided to try and use the minification from JavaScriptPacker, but not
its overly clever but generally useless packing techniques. The result
is a minifier that outperforms our current minifier in both how quickly
it can minify data and how small the minified output is.
JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript
code at about 2x the speed of Tim's optimized version of JSMin, and 4x
the speed of the next fastest PHP port of JSMin (which is generally
considered the standard distribution).
Similar to Tim's modified version of JSMin, we chose to retain vertical
whitespace by default. However we chose not to retain multiple
consecutive empty new lines, which are primarily seen where a large
comment block has been removed. We feel there is merit to the argument
that appx. 1% bloat is a reasonable price to pay for making it easier to
read production code, since leaving each statement on a line by itself
improves readability and users will be more likely to be able to report
problems that are actionable. We do not however find the preservation of
line numbers of any value, since in production mode most requests are
for many modules which are concatenated, making line numbers for most of
the code useless anyways.
This is a breakdown based on "ext.vector.simpleSearch"
* 3217 bytes (1300 compressed)
* 2178 bytes (944) after running it through the version of JSMin that
was in our repository. Tim modified JSMin to be faster and preserve line
numbers by leaving behind all vertical whitespace.
* 2160 bytes (938 compressed) after running it through
JavaScriptDistiller, which applies aggressive horizontal minification
plus collapsing multiple consecutive new lines into a single new line.
* 2077 bytes (923 compressed) after running it through
JavaScriptDistiller with the vertical space option set to true, which
applies aggressive horizontal minification as well as some basic
vertical minification. This option is activated through
$wgResourceLoaderMinifyJSVerticalSpace, which is false by default.
The code was committed in r80656.
- Trevor (and Roan)