> Message: 6
> Date: Sat, 2 Apr 2011 08:23:36 +0000 (UTC)
> From: Marcin Cieslak <saper(a)saper.info>
> Subject: Re: [Wikitech-l] Focus on sister projects
> To: wikitech-l(a)lists.wikimedia.org
> Message-ID: <slrnipdn7t.2e75.saper(a)saper.info>
> Content-Type: text/plain; charset=us-ascii
>
> >> MZMcBride <z(a)mzmcbride.com> wrote:
> > Ryan Kaldari wrote:
> >> Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing
> >> clean-up on a few wikis, but I usually just get chewed out by the local
> >> admins for not discussing every change in detail (which obviously
> >> doesn't scale for fixing 200+ wikis). I would love to hear ideas for how
> >> to address this problem.
> >
> > This caught my eye as Wikimedia has far more than 200 wikis. There seems to
> > be a shift happening within the Wikimedia Foundation. The sister projects
> > have routinely been ignored in the past, but things seem to be going further
> > lately....
>
> The good thing about forgotten/abandoned/unloved/etc. projects is that
> they probably don't have lots of cruft accumulated in the global CSS/JS
> files (as they require quite lively tech-savvy community to maintain them).
>
> So those sites will not probably require any changes and will survive
> HTML5 migration without any problems.
>
> //Marcin
On the contrary, I find the small language wiki projects to be in much
worse shape. Often they have syntax errors in their js files, breaking
_all_ js. Other times they have stuff that is just plain wrong. (Like
anyone remember the toolserver tool to gather stats before stuff was
available at http://dammit.lt/wikistats/ - where projects would put js
that pinged the toolserver once every 100 hits. That code is still in
many small projects [usually with the project code field set to the
wrong project]. I've even seen that code in wikis that were created
after said toolserver tool stopped working). On the other hand they
probably won't complain, as the js is already fairly broken ;)
-bawolff
(I just posted the following to the tech blog, http://techblog.wikimedia.org)
Last Monday, our Solaris server that contains all image thumbnails developed problems. It ran out of memory, became too slow and eventually even started to crash. (For the technically inclined: we think the kernel is leaking some file system structure in kernel memory.) This caused missing thumbnails across Wikimedia projects.
We addressed these problems in the following ways:
* We decreased the load on this server by adapting the Squid configuration, so it would have to handle fewer requests.
* We ordered more memory, in order to double the total physical memory in the relevant systems.
* We set up two new Linux servers that will eventually replace the Solaris server.
At first, the addition of these Linux servers in a partially caching setup seemed enough to fix the immediate problem, while gradually copying all thumbnail files, allowing us to replace the Solaris server completely.
However, on Saturday night the Solaris server started crashing repeatedly, making it necessary to engage the image scalers to regenerate a large part of the missing thumbnails. This is causing some slowness of loading and generating new (uncached) thumbnails.
Fortunately, most users have not experienced serious problems while using the site, since most thumbnails are cached by our HTTP caching layer. It is impossible to determine exactly how long it will take to recover completely from the slower service, but we expect that this will take no more than a few days.
Over the past months we have been developing a new and more scalable architecture for media storage, which will solve these problems once and for all. We hope to deploy this new architecture within a few months, also utilizing the new data center. Please watch the Tech Blog for updates on this project.
--
Mark Bergsma <mark(a)wikimedia.org>
Operations Engineering Program Manager
Wikimedia Foundation
In MediaWiki there are two preferences: "Disable AJAX suggestions" and
"Enable enhanced search suggestions (Vector skin only)".
They are problematic for several reasons:
1. Most average users don't know what AJAX is. It should be just
called "search suggestions".
2. The first option says "Disable", but the second one says "Enable".
It's confusing - both should say "Enable". "Disable AJAX suggestions"
should become "Enable search suggestions", and the value of the
checkbox must be reversed for all users.
3. Better yet, the two options should be merged into one. "Disable
AJAX suggestions" doesn't seem to do anything useful in Vector, no
matter whether it's checked or not, and "Enable enhanced search
suggestions (Vector skin only)", as its name implies is relevant only
for Vector. Separating them may have been useful in the early days of
Vector, but now that a year after the rollout Vector is rather stable,
this doesn't seem to be useful any more.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
"We're living in pieces,
I want to live in peace." - T. Moore
On Mon, Mar 28, 2011 at 7:20 AM, Aryeh Gregor <Simetrical+wikilist(a)gmail.com
> wrote:
> If, as Tim says, Wikimedia developers were un-assigned from code
> review after the 1.17 deployment, *that* is the problem that needs to
> be fixed. We need a managerial decision that all relatively
> experienced developers employed by Wikimedia need to set aside their
> other work to do as much code review as necessary to keep current. If
> commits are not, as a general rule, consistently reviewed within two
> or three days, the system is broken. I don't know why this isn't
> clear to everyone yet.
Hi Aryeh,
You say that as though this were obvious and uncontroversial. The reason
why we've been dancing around this issue is because it is not.
Right now, we have a system whereby junior developers get to commit whatever
they want, whenever they want. Under the system you outline, the only
remedy we have to the problem of falling behind is to throw more senior
developer time at the problem, no matter how ill-advised or low-priority the
changes the junior developers are making. Taken to an extreme, this means
that junior developers maintain complete control over the direction of
MediaWiki, with the senior developers there purely in a subservient role of
approving/rejecting code as it comes in.
What comes of this system should be obvious: senior developer burnout. If
only reward we offer for becoming an experienced developer is less
interesting work with less power over day-to-day work, we're not going to
attract and retain people in senior positions.
To be clear, none of the developers in WMF's General Engineering group have
been pulled off of code review. However, not all of the WMF's senior staff
are part of GenEng.
Rob
Dear fellow SVN users, if you encounter
$ svn update
...
svn: Failed to add directory 'config': an unversioned directory of the same name already exists
Then you had better move that directory and all its contents elsewhere,
and do "svn update" again, to avoid a half updated wiki.
Still trying to figure out what GSoC project to work on with the
Wikimedia Foundation? Want to work on something that will make a
profound impact, reaching people all over the world - both online AND
offline?
The Wikimedia offline [0] team is looking for a developer passionate
about leveraging Wikipedia and it sister projects for social good. We
are looking for someone to port the WP 1.0 Bot [1] to a Mediawiki
extension and expand its feature set. The WP 1.0 Bot is a critical tool
in the offline content creation tool chain. It simplifies the processes
of building collections of articles to be used offline while also
facilitating article quality assessment.
It's already being used to create offline versions of Wikipedia, but
communities all around the world have been asking for ways to build
their own offline collections of articles for use [2] in places where
access to to the same breadth and depth of knowledge as Wikipedia is not
available. Think: schools that do not or cannot have access to the
internet [3]; places where access to the web and certain types of
knowledge is restricted; or even just having the freedom to look up
Wikipedia articles without needing to be connected to the 'net.
The current tool lives on the Toolserver as a collection of Perl scripts
[4]. They require some degree of manual intervention at the code level
in order to run, are only primarily useful for en.wikipedia and
currently do not provide an easy way to manage article selections. We
want to port the tool to a Mediawiki extension and expand its feature
set so that it can be used by any of the wiki projects, make the process
of building article collections more accessible, be easy to translate
(via translatewiki.net) and have greater visibility/maintainability of
the code base. This is a crucial part of our overall effort to develop
a cohesive, easy to use suite of tools to simplify the offline content
creation process - we are exploring the possibilities of integrating
this with the Collection extension [5] (for article collection exports
in openZim format) as well as Kiwix [6], an application for reading and
searching openZim collections offline.
If this sounds like something up your alley, feel free to email me
directly or find me on irc.freenode.net (nick: awjr). I look forward to
reading your proposals :D
Arthur Richards
[0] http://meta.wikimedia.org/wiki/Offline_Projects
[1] http://en.wikipedia.org/wiki/User:WP_1.0_bot
[2] http://wikimedia.in/wiki/Projects:_Wikipedia_for_Schools/Indian_version
[3] http://schools-wikipedia.org/
[4] http://svn.toolserver.org/svnroot/p_enwp10/
[5] http://www.mediawiki.org/wiki/Extension:Collection
[6] http://www.kiwix.org/index.php/Main_Page