Hi everyone,
In case you missed it on the techblog, here's an update on the revised
deployment plan for 1.17, part 1 of which starts in 7 hours:
http://techblog.wikimedia.org/2011/02/1-17deployment-attempt2/
Also copied below.
Rob
------
As covered on this blog this week, we had a few problems with our
initial deployment of 1.17 to the Wikimedia cluster of servers. We’ve
investigated the problems, and believe we have fixed many of the
issues. Some of the unsolved issues are complicated enough that the
only timely and reasonable way to investigate them is to deploy and
react, so we’ve come up with a plan that lets us do it in a safe way
by deploying on just a few wikis at a time (as opposed to all at once,
as we tried earlier).
We’re scheduling two deployment windows:
First window – This wave will be deployed between Friday, February 11,
6:00 UTC – 12:00 UTC (10pm PST Thursday, February 10 in San
Francisco). This first wave will be to a limited set of wikis (see
below).
Second window – Wednesday February 16 (between 6:00 UTC – 12:00 UTC) –
full deployment (tentative)
Repeating what is new about 1.17: There are many, many little fixes
and improvements (see the draft release notes for an exhaustive list),
as well as one larger improvement: Resource Loader. Read more in the
previous 1.17 deployment announcement.
First window
This first deployment window will be to a limited set of wikis:
http://simple.wikipedia.org/ (simplewiki)
http://simple.wiktionary.org/ (simplewiktionary)
http://usability.wikimedia.org/ (usabilitywiki)
http://strategy.wikimedia.org/ (strategywiki)
http://meta.wikimedia.org/ (metawiki)
http://eo.wikipedia.org/ (eowiki)
http://en.wikiquote.org/ (enwikiquote)
http://en.wikinews.org/ (enwikinews)
http://en.wikibooks.org/ (enwikibooks)
http://beta.wikiversity.org (betawikiversity)
http://nl.wikipedia.org (nlwiki)
Note that the point of this first round of wikis being switched over
is to be able to observe the problem or problems without overloading
the site and bringing it down. This deployment should be small enough
in scope that even if there are moderate performance problems, no one
should notice without watching our monitoring tools. We may not roll
out to every wiki listed above during the first wave, but we plan to
roll out to enough of them that we can gather enough debugging
information to make the second wave (full deployment) go smoothly.
Second window
We will continue to roll this out to the rest of the wikis during this
window. Depending on our confidence level, we may deploy to the
remaining wikis, or we may decide to deploy to a portion of the
remaining wikis. If necessary, we will schedule another window to
finish the deployment.
Technical details
Here’s some more technical detail: one problem with the original
Tuesday deploy was that the cache miss rate went up quite
substantially. We believe the problem was a problem with the
configuration of the $wgCacheEpoch variable, which caused more
aggressive culling of our cache than the servers could handle. We
have made adjustments, and so this shouldn’t be a problem during our
next deployment attempt.
The $wgCacheEpoch problem explains some of the problems we had, but
not all of them. Since we don’t have a clear explanation for all of
the problems, we plan to modify the way we deploy this software so
that we aren’t rolling this out to every wiki simultaneously. As our
software is currently built, this isn’t easy to do in a general way,
but it turns out this release is suited to an incremental deployment.
(Note: we also plan to develop a more general capacity to roll out
incrementally for future releases).
Thank you for your patience! We hope that this time around we can
deploy this in a way that you won’t notice anything other than the
improvements.
Once again, I get the joys of bringing you all fun video streams! Today's
stream(s) comes from the Data Summit [1] at O'Reilly HQ. Unlike my last set
of feeds (WCWC11/WikiX), this one should be basically all presentations and
hopefully a little more interesting (though we don't have a good pull for
the projections, sorry). As usual, the stream only need VLC [2].
The URL for the stream is: http://transcode1.wikimedia.org:8080 - All you
need to do is launch VLC > Media > Open Network Stream.
I give you the standard "there is no warranty". I'm going to (hopefully)
add a second stream later in the day and I'll send out an update when that
happens. If you've got questions/comments - email me directly or message me
on irc.freenode.net/#wikimedia (Username is in my signature)
Thanks-
-Jon
[1] http://meta.wikimedia.org/wiki/Data_summit_2011
[2] http://www.videolan.org/vlc/
--
Jon
[[User:ShakataGaNai]] / KJ6FNQ
http://snowulf.com/http://ipv6wiki.net/
> There's a parallel talk into it chapter about gender gap. This gap is part
> of a larger gap involving software development in general; there are few
> programmer women. I presume, that this highlights a similarity between wiki
> and a software development environment; and really many from most
> enthusiast, and productive contributors are too programmers.
>
> But... as you know, the profile of a programmer is far from the profile of a
> woman; consider the famous statement "The three chief virtues of a
> programmer are: Laziness, Impatience and Hubris.". Then consider the pedia
> statement "Be bold!", that is a gentler way to name "hubris". :-)
>
> Is gender gap so mysterious?
>
> Alex
I would disagree with "Be Bold" = Hubris I have always thought "Be Bold" as
being about being comfortable with making mistakes. I certainly would consider
myself "bold" in general and more bold than the average woman in practical terms
on the wiki, but I still very much feel the Midwestern US taboo against thinking
too well of oneself and self-promoting which hubris should overcome. In my
experience boldness comes from a different place; that of having a trial and
error mentality to approaching the world in general. But I suppose boldness
could come from thinking oneself superior also.
> On 02/09/2011 11:18 PM, DaB. wrote:
> > sure. I asked the toolserver-database:
> >
> > en.wikipedia:
> > Male: 233312
> > Femaile: 46973
> > All user: 13959842
>
<snip>
>
> Now, if a woman uses a male pseudonym,
> she would obviously self-declare as a man,
> so we can't know if this correlates to real
> gender. We could only measure the setting.
>
I would hesitate to judge what might be a male pseudonym. In my experience any
pseudonym, given it is not displayed in pink or the userpage is not covered in
hearts or something, will be treated as male. I never intended to self-declare
as male, but was treated as male for many years. I did consciously decide to
accept what I perceived as the benefits of being treated as male and not correct
anyone. When someone years ago raised the argument that the lack of visibly
female Wikipedians might be a barrier to larger numbers of women joining
Wikipedia, I changed the coloring of my signature and don't remember being
treated as male since then.
Birgitte SB
I posted this on [Gendergap] mailing list at wikipedia but maybe this
mailing list is more relevant for technical details.
I posted on my blog the table about percentages of men/women on
different wikipedias.
See
http://www.gnuband.org/2011/02/10/percentage_of_men_and_women_on_different_…
On Russian Wikipedia, users tend to express their gender much more (16.80%!).
Amir left a comment saying that the User: namespace in Russian is
translated into the equivalent of User_male: (I guess if the user set
male in the preferences as gender) and User_female: (if female in the
preferences).
Do you know if this happens in other wikipedia as well?
In Russian Wikipedia, if gender is not set, how User: is rendered?
With the male equivalent or there is a neutral form?
P.
On Thu, Feb 10, 2011 at 4:39 PM, Joseph Reagle <joseph.2008(a)reagle.org> wrote:
> On Wednesday, February 09, 2011, Oliver Keyes wrote:
>> So, depressingly, it looks like en-wiki is actually doing the best! :P. Any
>> chance we could have that broken into percentages?
>
> My preliminary tabulation shows WP in the middle. Also, oddly, a lot of Russians apparently gender declare. One of the odd things with the survey from which the 13% is derived is how many Russians participated. Maybe the really like to identify with WP?
>
> en.wikipedia : 2.01% declared: 233312 men; 46973 women; women are 16.76%
> de.wikipedia : 3.47% declared: 35726 men; 4800 women; women are 11.84%
> fr.wikipedia : 2.16% declared: 18556 men; 3054 women; women are 14.13%
> commons : 2.26% declared: 27980 men; 5070 women; women are 15.34%
> sr.wikipedia : 2.66% declared: 1666 men; 414 women; women are 19.90%
> ru.wikipedia : 16.80% declared: 80491 men; 23750 women; women are 22.78%
> pl.wikipedia : 3.64% declared: 12106 men; 2999 women; women are 19.85%
> nl.wikipedia : 2.92% declared: 8977 men; 1781 women; women are 16.56%
>
> _______________________________________________
> Gendergap mailing list
> Gendergap(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/gendergap
>
--
--
Paolo Massa
Email: paolo AT gnuband DOT org
Blog: http://gnuband.org
--
--
Paolo Massa
Email: paolo AT gnuband DOT org
Blog: http://gnuband.org
>
> On 02/11/2011 12:24 AM, Platonides wrote:
> > And many don't even perform one edit. As I don't believe so many people
> > create them just to change their preferences, it is a mistery for me why
> > do they do so.
Creating an account also allows you to dismiss banners. My first step when I
have a minor issue with something is google search my complaint (i.e "fix excel
color palette screwed up"). I imagine googling "Wikipedia annoying banners go
away" during the fundraising period would get someone the proper instructions.
While I am not technical by any standards amoung Wikipedians, I am the causal
go-to technical person among my family and office. So I don't know how common my
methods might be among non-editors. But maybe word of mouth of from those that
like me that are unafraid of their technical ignorance to the complete Luddites
(that ask such people for help with "disappearing email" when they accidentally
minimize Outlook or dismiss the preview pane) could account for the spreading
these instructions.
Also some sites (I think Twitter is one) display very differently to people with
or without accounts. So some people may have a habit of signing up at all of the
websites they regularly consume.
Birgitte SB
Hi there,
Is there a WMF test wiki where I could play around with Flagged
Revisions without breaking anything? I'm interested in especially in
the configurations used on the major Wikipedias. Alternatively, is
there someplace where the configurations used are are explained? My
understanding is there are some differences in the usage patterns
between de.wp and en.wp, for instance.
Thanks,
Strainu
I've been experimenting with a mixed xml/html based template syntax for
skinning[1].
However I've been having issues with the parsing of it.
- DOMDocument::loadHTML throws warning and when I output it strips out
namespaces turning <mw:foo> into <foo>
- SimpleHTMLDOM was the most promising, in fact my current experiments
got very far with it, however when I got to the need to insert a node
before/after an element it completely messed up, I'm also not optimistic
of it's performance since there are no dom operations and it's "insert"
is essentially "concatenate some html with the outertext and set
outertext to it"
- html5lib choked on namespaces other than built-in handling of things
like svg: presumably.
- phpQuery is just a wrapper around DOMDocument
- tidy's plugin is supposed to support dom parsing, but that is not
deployed on every server, and even people using tidy through mw might
not be using the plugin since we support the executable as well. Not to
mention tidy seamed to share issues stripping or choking on <mw:...>
tags when it came to my editsection stuff. So even the idea of piping
through tidy then using loadXML on it is out.
- wiseparser, well I couldn't even get that to execute.
- XML_HTMLSax is so old and unmaintained I couldn't really get into
looking at it.
The requirements ideally are that it should support the normal html
parsing we already have (ie: boolean attributes and quoteless attributes
<div foo bar=baz>, perhaps the simple implicitly closed tags like <br>),
but also support parsing tags and attributes with mw: in them, in other
words XML namespaces.
Is there anyone willing to help out building a parser for it?
Possibilities could be custom parsing directly to dom, custom parsing
and calling a SAX-like api, or at it's simplest a light parser that
parses the html and outputs xml we can parse with loadXML instead (I
believe the issue in DOMDocument is it's html processing not issues with
namespaces), that would end up being a potential tidy replacement. Tidy
can't be used in this case because it too messes up namespaced stuff.
[1]:
http://www.mediawiki.org/wiki/User:Dantman/Skinning_system#xml.2Fhtml_templ…
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
A little bit before the scheduled deployment of the 1.17 branch on our
production servers, I will be halting production of XML dumps.
Deployment is set for Tuesday Feb 8 at 07:00 UTC, so a few hours before
that I'll start shutting down processes.
This is a precautionary measure; after the deployment and any hasty
fixes that may be needed, I will be doing some testing to ensure that
dumps are not impacted, before we restart them. Barring some bizarre
problem, we should be back up and running within a day or two.
Ariel
I've been making some improvements to the skin system for awhile now, so...
If you have a MediaWiki skin you've built, feel free to bring out it's
source code. Currently most of the few custom skins that exist are
floating around the Internet, and they are various degrees of out of
date. Bring up the source code, and I'll look into committing the skin
into svn and cleaning it up stripping away the boilerplate.
I would LOVE skin designs right now. If you've got a nice idea for a
skin feel free to mock it up and post the mockup images for it. If it
looks interesting I'll consider turning it into a real skin, ESPECIALLY
if it break our de-facto traditions on what makes up a wiki skin. Our
rigid skin structure is one of the big limitations of our skinning
system right now, skins that define things beyond the current
restrictions are good examples needed while we break open the rigid
structure of our skins.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]