The problem with our current VCS is the sort of work-flow that has
developed around it.
But we can solve the work-flow problem without introducing an entirely
new VCS and disrupting everything for a month or so while people adjust
to the new system.
The solution I'm proposing is that we branch 1.18 immediately after the
release of the 1.17 tarball.
Revisions marked “OK” (or, perhaps, tagged “118”) on the trunk could be
merged to the 1.18 branch. Or, to make merging into 1.18 less of a
chore for a single person, we could enable those doing code review to
merge code they've reviewed into the 1.18 branch. In this way, we
achieve Roan's (and my) goal of continuous integration.
This also put the onus on the individual developers to make sure that
their code gets reviewed and that problems found get fixed.
As a bonus, we could set a date *now* to make the 1.18 release and then
just release whatever is in the 1.18 branch on that day.
I think we need a few goals thrown in to make this really good — I
propose “1.18 will include a web UI for configuring MediaWiki” and “1.18
will cut the number of global variables in half” to pick two of my
personal favorites — but I think the work-flow of how MediaWiki is
prepared for release needs to be addressed.
Mark.
Hi,
I've found something strange in some files. The maximum ids for a page are:
latest
pages-articles.xml: 29189922
page.sql: 28707562
categorylinks.sql: 28705949
(15,684 categories and 135,521 articles are missing)
2011-01-15
pages-articles.xml: 30492297
page.sql: 30480288
categorylinks.sql: 30479519
Any idea why these numbers are different?
Thanks for your help,
Anthony
CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its content. Thank you.
Towards A Sustainable Earth: Print Only When Necessary
I talked to Hampton yesterday about the current Mobile site and, since
it was discussed here recently, I thought I'd try to update you all on
what he told me.
First, Hampton mentioned that while he, personally, isn't doing any work
on the Mobile rewrite (I think Tomasz Finc is trying to find someone to
do that), but he is still doing things like
* Adding new Wikis to the mobile proxy
(e.g. https://bugzilla.wikimedia.org/27290) At his request, I will be
adding the keyword “mobile-lang” to these requests so that he can
group them together
* Adding support for new UserAgent strings
(e.g. https://bugzilla.wikimedia.org/27257) He can update the mobile
proxy's support, but will need to rely on CSS files provided by the
community since he can't test all devices.
Note that Hampton cannot do things like adding new features
(e.g. https://bugzilla.wikimedia.org/25119) because of the PHP re-write.
Mark.
Hi,
I am trying to build an offline version of the wikipedia categorisation tree. As usual with projects on wikipedia, I've downloaded dumps (actually the interesting one here is pages-articles.xml). And I found that none of the dumps has the relation between "Category:1960_works" and "Category:1960" which is present on the web page. And it is the same for a lot of categories I tried: many links are missing in the dump, but are present in the web. Any idea why is that so?
Thanks for your help,
Anthony
CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its content. Thank you.
Towards A Sustainable Earth: Print Only When Necessary
Hi.
There are a few open bugs about adding mobile site support to a specific
Wikimedia wiki. For example, bug 27290 is about creating a mobile main page
for fa.m.wikipedia.org.[1]
What's the status of the mobile site / mobile site rewrite?[2] I'm mostly
curious because I think these open bugs can be made a dependency of the
rewrite bug, but that's only really true if development work has stopped on
the current mobile site implementation. I think I read that work had stopped
in a bug comment at some point (or at least it was intimated), but I'm not
sure.
Does anyone know what the current status is?
MZMcBride
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=27290
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=25558
Greetings,
As you may know, the Wikimedia teach team has started to upgrade
MediaWiki on some wikis. MediaWiki is the software that runs all
Wikimedia wikis.
The most visible change for Wikimedia users will be the deployment of
ResourceLoader [1].
ResourceLoader optimizes the use of JavaScript in MediaWiki, speeding up
its delivery by compressing it sometimes, and cutting down on the amount
of unused JavaScript that gets delivered to the browser in the first
place.
The installation of ResourceLoader may cause compatibility issues with
existing JavaScript code.
Trevor Parscal and Roan Kattouw, the main developers of ResourceLoader,
will be available on IRC [2] on Monday, February 14th, at 18:00 (UTC)
[3], to answer questions and help fix issues related to ResourceLoader.
*If you maintain JavaScript code on your home wiki, please attend.*
Don't wait until your wiki's JavaScript is all broken.
Please spread this information as widely as possible; it's critical to
reach as many local JavaScript maintainers as possible.
Logs of the session will be published publicly.
[1] http://www.mediawiki.org/wiki/ResourceLoader
[2] http://meta.wikimedia.org/wiki/IRC_office_hours
[3] All timezones: http://ur1.ca/3819u
--
Guillaume Paumier
Product manager - Wikimedia Foundation
Support free knowledge: http://donate.wikimedia.org
Hi,
While working on fixing gadgets etc. I just noticed mediawiki.org
itself was not part of the first wave
(I confused it with metawiki I guess).
Is there any issues with switching to 1.17wmf1 before the rest goes
(say tonight or Monday) ? Currently
I'm writing some documentation but the 'new' versions of things don't
actually work on mw.org so it's
hard demonstrating it, since it won't work on mediawiki.org
I could move things to Meta-Wiki and back again, but since mw.org is a
relatively small wiki I think
there wouldn't be any load issues (is that still an issue?) in
switching it before the 'final wave'.
The reason I'm writing these things now instead of Wednessday is because
A) Some wikis are already switched and they're screaming about broken
gadgets which need updating.
Since these gadgets are usually copied from MW.org fixing them there
now results in them being
broken on MW.org
B) I like to get things ready before the actual switch is made so that
when the switch is made, people can
update things right away.
--
Krinkle
To start out with catching up on patch review, I took a look over and
applied the patches on bug 23817, fixing wfObjectToArray() and FormatJson
for a case that broke certain parts of ForeignAPIRepo when PHP's native JSON
module wasn't present:
https://bugzilla.wikimedia.org/show_bug.cgi?id=23817
The patches were posted by Tim Yates shortly after his bug report in June
2010; the same bug was re-filed in December as bug 26250, and only
reconnected later. Thanks for the fix, Tim!
-- brion
One-line fix for search suggestions for special pages where the alias
contains spaces (happens a lot more in non-English localizations).
Patch was submitted by Umherirrender in October 2010:
https://bugzilla.wikimedia.org/show_bug.cgi?id=25675
-- brion