[Wikitech-l] https://github.com/mediawiki/ is now up again
It's been re-cloned and is being updated every 10 minutes. Note that this was a non-fast-forward updates, so git pull on existing checkouts won't work, you'll have to re-clone. On the plus side this is now being cloned directly from svn, e.g. this is the latest commit: git-svn-id: svn+ssh://svn.wikimedia.org/svnroot/mediawiki/trunk@86256 dd0e9695-b195-4be7-bd10-2dea1a65a6b6 This means that using this to bootstap your own git-svn checkout (to use for further development) should be possible now, but I don't have instructions for how to do that, patches to http://www.mediawiki.org/wiki/Git#Rebuilding_SVN_metadata welcome. Note that this is still out of date: http://gitorious.org/mediawiki I don't know who maintains it, but if there's demand for having one on gitorious I'd be happy to update that one too. It's just a matter of adding a couple of extra pushes here: https://github.com/avar/mediawiki-mirror/blob/master/mediawiki-mirror.sh#L22 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] https://github.com/mediawiki/ is now up again
On Sun, Apr 17, 2011 at 19:32, Brion Vibber br...@pobox.com wrote: I took it over from the previous person who was mirroring at it a couple months ago; I actually set you up with admin permissions, so feel free to set up the automatic pushes. :D It's now pushing to gitorious too. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Converting to Git?
On Tue, Mar 22, 2011 at 15:25, Siebrand Mazeland s.mazel...@xs4all.nl wrote: Please convince me that things will not be as hard as I describe above, or will most definitely not turn out as I fear. I am open to improvements, but moving to GIT without addressing these concerns for the sake of having this great DVCS is not justified IMO. I think the last time this came up I asked you why the difficulty of what you have to do is a function of the number of repositories you have to push to. That shouldn't be the case, that's trivially scriptable. You'd still be reviewing the same *content*. You'd just push to more locations. So it's easy to get this right for you in Git, and you're the only person AFAIC with this use case. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Converting to Git?
On Tue, Mar 22, 2011 at 16:33, Max Semenik maxsem.w...@gmail.com wrote: On 22.03.2011, 18:08 Trevor wrote: Your objections seem to be based on the assumption that you would need to have push access to all repositories, but I think that's the point of DCVS, you can just fork them, and then people can pull your changes in themselves (or using a tool). Pull requests could even be generated when things are out of sync. I think it's quite possible this could make i18n/L10n work easier, not more difficult. You seem to miss Siebrand's point: curerently, all localisation updates take one commit per day. Splitting stuff to separate repos will result in up to 400 commits per day that will also need to be pushed and reintegrated - an epic waste of time and common sense. Or localisation will simply lie aside in forks and people will miss them when checking out from the official source. I think you're missing the point that there's no reason why 400 commits should be harder than 1 in this case. When he makes a commit now he ends up stat()-ing 400 files, but he doesn't notice because it's all abstracted away. Similarly he could make 400 commits by issuing one command, just like he does today. And what does pushed and reintegrated mean? He'd presumably push to the canonical upstream, just like he does now. (Or he could push somewhere else if people would like that, pulling from that should also be trivial). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GitHub Mirror of the svn repository
On Wed, Mar 16, 2011 at 19:26, Yuvi Panda yuvipa...@gmail.com wrote: I noticed that there's a github mirror of the svn repository at https://github.com/mediawiki, but it is rather out of date. Any idea if/when it could be made up-to-date again? I've been busy / out of town so I haven't fixed the MediaWiki mirror in GitHub yet. I'll do so soon. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Converting to Git?
On Sun, Mar 20, 2011 at 14:21, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: On Wed, Mar 16, 2011 at 19:26, Yuvi Panda yuvipa...@gmail.com wrote: I noticed that there's a github mirror of the svn repository at https://github.com/mediawiki, but it is rather out of date. Any idea if/when it could be made up-to-date again? I've been busy / out of town so I haven't fixed the MediaWiki mirror in GitHub yet. I'll do so soon. I'm now re-running git-svn clone on the relevant paths (lost the original), once that's complete I can update the mirror again. I'm cloning from svn+ssh:// this time instead of my pushmi mirror file://, so people cloning this should be able to push upstream with git-svn without using git-filter-branch to rewrite the history first. But actually the reason I did this mirror was as a proof of concept for a (still incomplete) conversion to Git. Is there still interest in that? I don't have a lot of time for it, but I could help with that if people want to go that way. I don't care much myself since I don't do MediaWiki development anymore, but I'd be happy to help with it. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposed hooks for Vector
On Thu, Jul 8, 2010 at 09:13, Roan Kattouw roan.katt...@gmail.com wrote: Although I agree that having hooks for these things would be nice, wouldn't it suffice for your purposes to just hide these things with CSS? I could probably get away with it. But I'd rather munge the output than count on CSS, so the site wouldn't look different on some limited mobile devices, or text browsers. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Proposed hooks for Vector
I run a custom Vector installation for a corporate-ish setup. Since
the wiki is readonly unless people log in I've hidden some of the
scarier wiki stuff. Here's my diff of Vector.php:
Index: skins/Vector.php
===
--- skins/Vector.php(revision 68624)
+++ skins/Vector.php(working copy)
@@ -435,13 +435,13 @@
'tagline',
),
'places' = array(
- 'privacy',
- 'about',
- 'disclaimer',
+# 'privacy',
+# 'about',
+# 'disclaimer',
),
'icons' = array(
- 'poweredbyico',
- 'copyrightico',
+# 'poweredbyico',
+# 'copyrightico',
),
);
$footerlinksClasses = array(
@@ -582,7 +582,7 @@
private function renderPortals( $portals ) {
// Force the rendering of the following portals
if ( !isset( $portals['SEARCH'] ) )
$portals['SEARCH'] = true;
- if ( !isset( $portals['TOOLBOX'] ) )
$portals['TOOLBOX'] = true;
+# if ( !isset( $portals['TOOLBOX'] ) )
$portals['TOOLBOX'] = true;
if ( !isset( $portals['LANGUAGES'] ) )
$portals['LANGUAGES'] = true;
// Render portals
foreach ( $portals as $name = $content ) {
I could just add hooks to munge those things. E.g.:
wfRunHooks( 'SkinVectorExecuteFooterlinks, array( $this,
$footerlinks ) );
And:
wfRunHooks( 'SkinVectorRenderPortalsPortals, array( $this, $portals ) );
But I thought I'd ask if someone (particularly Trevor) has suggestions
on how to do it better. I can't see a quick and sane way to do it for
the general case, since Vector uses a diffrent $footerlinks structure
than MonoBook.
That's fine for my purposes, but might not be such a good idea for
MediaWiki. I think per-skin hooks aren't an inherently bad idea
though.
It would be used similar to how you can use SkinBuildSidebar now,
here's something from my LocalSettings.php:
# Hide scary stuff in the sidebar from users that aren't logged
in. Derived from
#
http://www.mediawiki.org/wiki/Manual:Interface/Sidebar#Change_sidebar_content_when_logged_in_.28PHP.29
$wgHooks['SkinBuildSidebar'][] = 'efHideSidebar';
function efHideSidebar($skin, $bar) {
global $wgUser;
if (!$wgUser-isAllowed( 'edit' )) {
unset($bar['vf-navigation-users']);
unset($bar['TOOLBOX']);
}
if (!$wgUser-isAllowed( 'block' )) {
unset($bar['vf-navigation-admins']);
}
return true;
}
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] VP8 freed!
On Thu, May 20, 2010 at 06:28, Gregory Maxwell gmaxw...@gmail.com wrote: This is pretty far off topic, but letting fud sit around is never a good idea. Sure, VP8 looks very interesting. I hope it takes off and we get a good enough patent-free codec that's more modern than Theora. On the patent part— Simply being similar to something doesn't imply patent infringement, Jason is talking out of his rear on that point. He has no particular expertise with patents, and even fairly little knowledge of the specific H.264 patents as his project ignores them entirely. I don't know anything about the patents involved, but his comments in e.g. the Intra Prediction section are very specific, he cites H.264’s spatial intra prediction is covered in patents. He's clearly done some research and is pointing out a very specific patent-covered feature in H.264 that's very similarly implemented in VP8. Google is putting their billion dollar butt on the line— litigation involving inducement to infringe on top of their own violation could be enormous in the extreme. They're already paying the H.264 patent fees, any infringements of those are likely to involve a few million dollars/year of patent fees. Not their billion dollar butt. Hardly putting their butt on the line, that would be promising to cover any downstream patent infringement. Which they're explicitly not doing. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki GitHub mirror now running
On Sun, May 9, 2010 at 07:37, Liangent liang...@gmail.com wrote: Is it possible to mirror branches in SVN there as well? It's unclear due to top-posting what there means. You can do it with the mediawiki-svn repository, but the mediawiki-trunk-* repositories just clones of trunk, so no. If you want branches too just bite the bullet and use the giant mediawiki-svn repository. I could in theory produce a mirror of just */phase3 with branches. But I'd need a list of branches that are derived from phase3, and not just some extension. It also doesn't help that some people just copy some subdir around instead of making the branch/* tree mirror some subset of trunk/*, e.g.: * http://svn.wikimedia.org/svnroot/mediawiki/branches/hashar/ * http://svn.wikimedia.org/svnroot/mediawiki/branches/CentralNotice-delayed-load/ * ... I personally prefer to put different extensions in different repos since I cannot clone a subdirectory in a repo only. Me too. But we have more than 400 extensions. For that to be practical I'd have to write a program to automatically spawn new repositories through the GitHub API maintain them. I don't have that yet. I'd also have to either use 'git filter-branch' after every update to filter out extensions/*, or git svn fetch for each one, or devise some system to fetch changes and apply them to each repository as needed. The first too are expensive, the second is messy and non-trivial to get right. Anyway. I just uploaded some mirrors now that were easy to do (and mediawiki-trunk-extensions is there now). If you want something more I'd be happy to do that if it's easy, and I'd be even happier to accept patches against the mirroring scripts. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Technical means for tagging content (was: [Foundation-l] Statement on appropriate educational content)
On Sun, May 9, 2010 at 12:36, K. Peachey p858sn...@yahoo.com.au wrote:
For example, Showing real content, There is a difference in adding any
of the three to a filter list:
* http://en.wikipedia.org/wiki/Category:Cats (The Category)
* http://en.wikipedia.org/wiki/File:ParliamentaryCats.jpg (The Description
Page)
* http://upload.wikimedia.org/wikipedia/en/e/ec/ParliamentaryCats.jpg
(The Actual File)
The last one (and the subsequent thumb files) is what we need to be
easily identifiable [The Filenames and Full Paths] so they can be
dealt with as required by the filters, For example a list that is
automatically produced per category so they can be imported (Is there
any standards for importable lists into filters??).
It's pretty easy to do arbitrary content tagging (and filtering now).
You just add a template or external link to the page. E.g. {{PG-13}}.
Then all some third party has to do is to download
templatelinks.sql.gz (or externallinks.sql.gz) in addition to the
image dump.
You just have to start getting people to tag things consistently. The
good thing is that you can start now without any additional software
support.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki GitHub mirror now running
The long dormant MediaWiki GitHub mirror is now running again. It's now lagging 10 minutes behind the MediaWiki repository at most: http://github.com/mediawiki/mediawiki-svn The mirror contains all MediaWiki branches and tags. It's currently 360MB, with a full checkout being another 320MB. Once I figure out how to reconstruct the SVN metadata from a checkout (http://github.com/mediawiki/mediawiki-svn/issues#issue/1) you'll be able to follow these instructions: http://www.mediawiki.org/wiki/Subversion#Using_the_GitHub_mirror And do: 1. Check out MediaWiki from Git 2. Hack a bunch 3. Push back to Subversion I'm also planning on having other repositories for selected subsets of the MediaWiki SVN. Similar to what I've already set up for the OpenStreetMap SVN repository: http://github.com/openstreetmap That is, you'll be able to clone just trunk/phase3 or trunk/extensions via Git without getting all the other stuff you don't care about. Here are the scripts that sync the mirror, for the curious: http://github.com/avar/mediawiki-mirror http://github.com/avar/git-anyonecanedit-etc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki GitHub mirror now running
On Sat, May 8, 2010 at 14:22, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: I'm also planning on having other repositories for selected subsets of the MediaWiki SVN. Similar to what I've already set up for the OpenStreetMap SVN repository: trunk/phase3 is now up: http://github.com/mediawiki/mediawiki-trunk-phase3 trunk/extensions will follow soon: http://github.com/mediawiki/mediawiki-trunk-extensions ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC project advice: port texvc to Python?
On Tue, Mar 30, 2010 at 14:34, Victor bob...@ua.fm wrote: Actually I completely disagree. Since I've got some experience with both OCaml and PHP the idea to convert Maths processing to PHP looks like a not so good idea at all. Probably the issues you had were more like a wrong/problematic configuration or something like that. OCaml itself is actively developed and is a mature language and development environment, much better than PHP or Python (IMHO). It is just interesting to wait a bit and compare the PHP and OCaml implementations of texvc (if there will be anything at all to compare). c is better, so is Common Lisp, Scheme, Haskell, Clojure or a number of other languages. The problem is that worse is better. OCaml isn't widely known among programmers or as easy for PHP programmers to get into as say Perl, Python or Ruby. As a result the math/ directory has been untouched (aside from the stray doc+bug fix) since 2003. There are many long standing core issues with the texvc component in Bugzilla (http://bit.ly/bsSUPM) that noone is looking at. I don't think anyone would have a problem with it remaining in OCaml if it was being maintained and these long-standing bugs were being fixed. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC project advice: port texvc to Python?
On Wed, Mar 31, 2010 at 10:58, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: c is better That should have been OCaml. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC project advice: port texvc to Python?
On Wed, Mar 31, 2010 at 14:24, Tei oscar.vi...@gmail.com wrote: Doing Math in any programming language or digital computer is a bad idea. Anyway. The texvc component doesn't do math. It just sanitizes LaTeX and passes it off to have a PNG generated from it. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] hiphop progress?
On Fri, Mar 26, 2010 at 20:00, Ryan Bies r...@yaauie.com wrote: [...] I don't know the answer to your question but can we please get this hiphop work into SVN and out of various patchsets floating around? Let's just create a hiphop branch for it so we can all experiment with it. It looks like you don't have SVN commit access. Please ask for an account to commit this stuff. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Cite extension- extra functionality
On Wed, Mar 17, 2010 at 20:48, Nimish Gautam ngau...@wikimedia.org wrote: Hey all, I wanted to change the cite extension to have some extra functionality. As citations have gotten more common, I've noticed an emerging use case where people will copy and paste text from wikipedia to HTML-enabled tools such as email clients or IM clients to share information. Unfortunately, those citation links just link to anchors on the page and don't provide anything useful when copied/pasted. Appending the full page's URL to those links would take like 20 seconds, make them functional, but would add extra markup to every page. Anyone have any other good reasons why we shouldn't do this? As Conrad pointed out using non-absolute URLs like this is by design and not doing so would break other functionality. What browser are you using and how are you copy-pasting the HTML from the browser to your E-Mail/IM programs? If it's some feature where you highlight a text on the page and the browser automatically fetches the underlying HTML then not resolving anchor links on the page sounds like a bug in that browser. Are are you just viewing the source of the page and copy/pasting snippets from there? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New committer
On Wed, Mar 10, 2010 at 13:24, Andrew Garrett agarr...@wikimedia.org wrote: On 11/03/10 12:21 AM, Roan Kattouw wrote: 2010/3/10 Chadinnocentkil...@gmail.com: I see he already has his account linked on-wiki and committed a USERINFO file. Can the recently added people for Calcey and LQT (bhagya, janesh, ishimatsu) be notified of these two things as well? Have no clue if they're on this list. Having an account with e-mail linked in CR is especially important. I forwarded this e-mail to Bhagya and Janesh; I don't have ishimatsu's contact details. Andrew, do you? There are about five new committers for multilingual LiquidThreads, for whom I have contact information that I have not yet added to USERINFO. They have MediaWiki.org accounts not yet linked to their commit accounts. I'll get this sorted in the next few days. Are new commiters being sent a link to [1] when they get their commit access? 1. http://www.mediawiki.org/wiki/Commit_access#Getting_started_and_set_up ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] hiphop progress
On Mon, Mar 1, 2010 at 10:10, Domas Mituzas midom.li...@gmail.com wrote: Howdy, Most of the code in MediaWiki works just fine with it (since most of it is mundane) but things like dynamically including certain files, declaring classes, eval() and so on are all out. There're two types of includes in MediaWiki, ones I fixed for AutoLoader and ones I didn't - HPHP has all classes loaded, so AutoLoader is redundant. Generally, every include that just defines classes/functions is fine with HPHP, it is just some of MediaWiki's startup logic (Setup/WebStart) that depends on files included in certain order, so we have to make sure HipHop understands those includes. There was some different behavior with file including - in Zend you can say require(File.php), and it will try current script's directory, but if you do require(../File.php) - it will We don't have any eval() at the moment, and actually there's a mode when eval() works, people are just scared too much of it. We had some double class definitions (depending on whether certain components are available), as well as double function definitions ( ProfilerStub vs Profiler ) One of major problems is simply still not complete function set, that we'd need: * session - though we could sure work around it by setting up our own Session abstraction, team at facebook is already busy implementing full support * xdiff, mhash - the only two calls to it are from DiffHistoryBlob - so getting the feature to work is mandatory for production, not needed for testing :) * tidy - have to call the binary now function_exists() is somewhat crippled, as far as I understand, so I had to work around certain issues there. There're some other crippled functions, which we hit through the testing... It is quite fun to hit all the various edge cases in PHP language (e.g. interfaces may have constants) which are broken in hiphop. Good thing is having developers carefully reading/looking at those. Some things are still broken, some can be worked around in MediaWiki. Some of crashes I hit are quite difficult to reproduce - it is easier to bypass that code for now, and come up with good reproduction cases later. Even if it wasn't hotspots like the parser could still be compiled with hiphop and turned into a PECL extension. hiphop provides major boost for actual mediawiki initialization too - while Zend has to reinitialize objects and data all the time, having all that in core process image is quite efficient. One other nice thing about hiphop is that the compiler output is relatively readable compared to most compilers. Meaning that if you That especially helps with debugging :) need to optimize some particular function it's easy to take the generated .cpp output and replace the generated code with something more native to C++ that doesn't lose speed because it needs to manipulate everything as a php object. Well, that is not entirely true - if it manipulated everything as PHP object (zval), it would be as slow and inefficient as PHP. The major cost benefit here is that it does strict type inference, and falls back to Variant only when it cannot come up with decent type. And yes, one can find offending code that causes the expensive paths. I don't see manual C++ code optimizations as way to go though - because they'd be overwritten by next code build. The case I had in mind is when you have say a function in the parser that takes a $string and munges it. If that turns out to be a bottleneck you could just get a char* out of that $string and munge it at the C level instead of calling the PHP wrappers for things like explode() and other php string/array munging. That's some future project once it's working and those bottlenecks are found though, I was just pleasantly surprised that hphp makes this relatively easy. One large practical upshot of this is though that hacky things like the parser which are the way they are because that's how you optimize this sort of thing in PHP could be written in some babytalk version of PHP that produces a real parse tree; It would be slower in pure php but maybe hphp's speed could make up for it. Then you could take that component compile it to C++ (maybe with some manual munging) and make libmediawiki-parse++ which, that would be quite awesome :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] hiphop progress
On Mon, Mar 1, 2010 at 13:35, Domas Mituzas midom.li...@gmail.com wrote: Still, the decision to merge certain changes into MediaWiki codebase (e.g. relative includes, rather than $IP-based absolute ones) would be quite invasive. Also, we'd have to enforce stricter policy on how some of the dynamic PHP features are used. I might be revealing my lack of knowledge about PHP here but why is that invasive and why do we use $IP in includes in the first place? I did some tests here: http://gist.github.com/310380 Which show that as long as you set_include_path() with $IP/includes/ at the front PHP will make exactly the same stat(), read() etc. calls with relative paths that it does with absolute paths. Maybe that's only on recent versions, I tested on php 5.2. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] hiphop! :)
On Sun, Feb 28, 2010 at 21:33, Domas Mituzas midom.li...@gmail.com wrote: Nevertheless - a process isn't the same process when it's going at 10x the speed. This'll be interesting. not 10x. I did concurrent benchmarks for API requests (e.g. opensearch) on modern boxes, and saw: HipHop: Requests per second: 1975.39 [#/sec] (mean) Zend: Requests per second: 371.29 [#/sec] (mean) these numbers seriously kick ass. I still can't believe I observe 2000 mediawiki requests/s from a single box ;-) Awesome. I did some tryouts with hiphop too before you started overtaking me. Is this work on SVN yet? Maybe it would be nice to create a branch for it so that other people can poke it? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] hiphop! :)
On Sun, Feb 28, 2010 at 21:39, David Gerard dger...@gmail.com wrote: On 28 February 2010 21:33, Domas Mituzas midom.li...@gmail.com wrote: these numbers seriously kick ass. I still can't believe I observe 2000 mediawiki requests/s from a single box ;-) So ... how restricted is HipHop PHP, and what are the hotspots in MediaWiki that would most benefit from it? Most of the code in MediaWiki works just fine with it (since most of it is mundane) but things like dynamically including certain files, declaring classes, eval() and so on are all out. It should be possible to replace all that at the cost of code that's a bit more verbose. Even if it wasn't hotspots like the parser could still be compiled with hiphop and turned into a PECL extension. One other nice thing about hiphop is that the compiler output is relatively readable compared to most compilers. Meaning that if you need to optimize some particular function it's easy to take the generated .cpp output and replace the generated code with something more native to C++ that doesn't lose speed because it needs to manipulate everything as a php object. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Google phases out support for IE6
On Thu, Feb 4, 2010 at 14:37, Aryeh Gregor simetrical+wikil...@gmail.com wrote: On Wed, Feb 3, 2010 at 5:11 PM, Trevor Parscal tpars...@wikimedia.org wrote: Are the stats setup to differentiate between real ie6 users and bing autosurfing? I'd be pretty surprised if Bing is generating enough traffic to noticeably affect the percentage, even if it does get counted as IE6. Bing can hit you pretty hard: http://blogs.perl.org/users/cpan_testers/2010/01/msnbot-must-die.html ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Only 132 / 252 SVN users have valid USERINFO data
On Sun, Feb 21, 2010 at 00:27, Aryeh Gregor simetrical+wikil...@gmail.com wrote: On Fri, Feb 19, 2010 at 6:45 PM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: If you're one of the guilty or know the contact info for them please add it to USERINFO/ Probably some people don't want to publish their real name or e-mail address publicly. They should still add a USERINFO file. You can just set name to your nickname (or SVNID) and email: to an empty value to specifically. A non-public E-Mail is more odd, if you do any development on MediaWiki then you're going to use Bugzilla or MediaWiki-l or Wikitech-l which all require an E-Mail address and will make it public without any attempt at obfuscation. But if you *really* don't want a public E-Mail address if we convert to Git despite that then you can just put an empty email: key in the USERINFO file. On Fri, Feb 19, 2010 at 10:09 PM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: What we're trying to do is: * Set up a git-svn mirror on github which people can use to work with MediaWiki's SVN through Git We've been given free hosting by Github to do this there: http://support.github.com/discussions/site/1281-are-you-interested-in-giving-me-free-space-to-host-mediawikigit Even if you don't want to use git-svn it's nice to have a mirror or Github just because it makes it easy for a lot of people already there to follow the project. IMO, we want git hosting on Wikimedia servers. With git, it's trivial to move the actual repository later, but it's not trivial to update all the links people have been using. I don't want a repeat of the situation with SourceForge, where we had people downloading ancient versions of MediaWiki for years because we couldn't point SourceForge to the new official site. That *is* a very real risk if we're using hosting we don't control. If people prefer working with github, of course, we could have the official(-er) one at git.wikimedia.org, and keep a copy at github that automatically pulls from the Wikimedia one. But I really don't think we want to point people to github.com URLs as the *primary* source to get MediaWiki via git, just as a secondary option. We don't even have a working conversion yet, talking about eventual hosting for the Official Wikimedia Git if and when it happens is really premature. The issues you cite with SourceForge aren't going to be a problem anywhere else though; SF is a really special case of a fail singularity :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Only 132 / 252 SVN users have valid USERINFO data
I'm experimenting with converting the MediaWiki SVN repository to Git. To do that properly commits need to be rewritten to turn SVN commiter ID's like avar into name/email pairs like Ævar Arnfjörð Bjarmason/ava...@gmail.com. We have a USERINFO directory in SVN that keeps metadata for commiters, unfortunately it's far from complete. Out of around 250 commiters only 132 have valid USERINFO data at all, and some of the users that do have data are missing a name, email or both. Those are: Users with no name: key: bawolff filnik huji nikerabbit overlordq robin soxred93 sql thomasv Users with no email: key: a_engels aaron allyunion cydeweys danny_b filnik gerrit hooft huji j jasonr jhb lrbabe misza13 mulligen quistnix rikwade russblau sanbeg straussd valhallasw warddr wikipedian And finally, users with no info at all: aboostani adam adammck adhair ajvol alnokta angelab aoineko_jp axelboldt bartek beckr bradneuberg b_stancescu chrisseaton christianlist danenberg diana dschwen e23 eflebeth egilk eloquence emiller evanprodromou ezachte fredck fvassard gabrielwicke gmaxwell greenreaper gri6507 harddisk hidders ilyah imsop jeronim jitseniesen jonwilliford jostrow karstenuil kateturner kelson42 kipcool knutux lcrocker looxix luca lupin lupin-wp maarten magnus_manske maikmerten malvineous markcdeckert markj marumari matjordan mej millosh minuteelectron nicdumz nimishg (no author) nojhan npassoc oggk op_kai platonides proes robh rodasmith root ryo_saeba shaihulud shaneking sj_kissane skierpage smurf-wiki stipe strainu tarquindarkling taw timwi tomgilder tparscal uid23179 urichj00 wmahan zhengzhu zilche If you're one of the guilty or know the contact info for them please add it to USERINFO/ For the curious this is the tool that did the analysis: http://github.com/avar/mediawiki-userinfo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Only 132 / 252 SVN users have valid USERINFO data
On Sat, Feb 20, 2010 at 02:43, Chad innocentkil...@gmail.com wrote: On Fri, Feb 19, 2010 at 9:38 PM, Liangent liang...@gmail.com wrote: Will MediaWiki repository be moved to Git? Some people want to move to git. Some people like other DCVSes. There is a git mirror and running over on GitHub now[1] that you're free to fork and play with. There are no set-in-stone plans for anything right now, just some mumblings by a few people. -Chad [1] http://github.com/mediawiki/mediawiki-svn Right. As Chad says this is just a project to make a conversion to Git. Whether anyone ends up using it or not is another issue. What we're trying to do is: * Set up a git-svn mirror on github which people can use to work with MediaWiki's SVN through Git We've been given free hosting by Github to do this there: http://support.github.com/discussions/site/1281-are-you-interested-in-giving-me-free-space-to-host-mediawikigit Even if you don't want to use git-svn it's nice to have a mirror or Github just because it makes it easy for a lot of people already there to follow the project. * Convert the MediaWiki Subversion repository to something that looks native in Git This involves splitting up the repository rewriting commits. See this E-Mail for info: http://lists.wikimedia.org/pipermail/wikitech-l/2010-February/046667.html There are outstanding issues with both of these which I've filed in a tracker at Github here: http://github.com/mediawiki/mediawiki-svn/issues If you (or anyone else) is interested in helping either one of those happen then by all means join us. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extensions in SVN looking for a maintainer
On Fri, Feb 12, 2010 at 19:00, Siebrand Mazeland s.mazel...@xs4all.nl wrote: List of extensions used by Wikimedia without a Bugzilla maintainer: * Cite The Cite special page and parser hook extensions. I wrote it, it's high profile and seems to have been somewhat unloved since I left it. I've looked at it a few times since then with the intent of fixing it up but I never got past the point of looking at Bugzilla and trying to determine what was actually needed for it and what was just the minority report of some user wanting some feature that him and 3 other people in the world are ever going to use. Domas has also complained that it eats up resources. Is this something that can conceivably be fixed in it or is it just inherent in anything that calls the parser from an extension tag and will thus need parser fixups to get anywhere? * Newuserlog The Newuserlog extension. I can take it. It's not like it needs much maintenance. * CrossNamespaceLinks The CrossNamespaceLinks special page extension. Ditto. * Desysop Desysop extension Isn't this also covered by UserRights? (I don't know). * Espionage The Espionage extension. That's CheckUser, does that one have a maintainer? * Eval The Eval special page extension. I patched it up a bit. It's not like anyone other than me has actually ever used it. But sure, I'll take it. * PageCSS The PageCSS parser hook extension. I'll take it, not that anyone cares. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New phpunit tests eat ~1GB of memory
On Sat, Feb 6, 2010 at 01:04, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: Since the tests were ported from t/ to phpunit's phase3/maintenance/tests/ in r61938 and other commits running the tests on my machine takes up to 1GB of memory and grows as it runs more tests. It seems that phpunit uses the same instance of the php interpreter for running all the tests. Is there some way around this? Perhaps phpunit.xml could be tweaked so that it runs a new php for each test? Furthermore when I run `make test' I get this: Time: 03:35, Memory: 1849.25Mb There were 2 failures: 1) LanguageConverterTest::testGetPreferredVariantUserOption Failed asserting that two strings are equal. --- Expected +++ Actual @@ @@ -tg-latn +tg /home/avar/src/mw/trunk/phase3/maintenance/tests/LanguageConverterTest.php:82 2) Warning No tests found in class ParserUnitTest. FAILURES! Tests: 686, Assertions: 3431, Failures: 2, Incomplete: 34 But when I run phpunit manually on the test then all tests pass: $ phpunit LanguageConverterTest.php PHPUnit 3.4.5 by Sebastian Bergmann. . Time: 23 seconds, Memory: 23.75Mb OK (9 tests, 34 assertions) Also after I get Tests: 686, Assertions: 3431, Failures: 2, Incomplete: 34 in the first output phpunit doesn't exit and continues hugging my memory. Why is it still running? It has already run all the tests. I've worked around this by adding a 'make tap' target which runs the phpunit tests individually with Test::Harness. I made it the default target due to the problems with running all the tests at once with phpunit: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/62071 http://www.mediawiki.org/wiki/Special:Code/MediaWiki/62072 Does something run these tests or the parsertests automatically? It would be really neat to test all svn revisions of MediaWiki and report the results on Special:Code. I think I read somewhere that something runs the parsertests automatically. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New phpunit tests eat ~1GB of memory
On Sat, Feb 6, 2010 at 16:27, Chad innocentkil...@gmail.com wrote: On Sat, Feb 6, 2010 at 11:24 AM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: On Sat, Feb 6, 2010 at 01:04, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: Since the tests were ported from t/ to phpunit's phase3/maintenance/tests/ in r61938 and other commits running the tests on my machine takes up to 1GB of memory and grows as it runs more tests. It seems that phpunit uses the same instance of the php interpreter for running all the tests. Is there some way around this? Perhaps phpunit.xml could be tweaked so that it runs a new php for each test? Furthermore when I run `make test' I get this: Time: 03:35, Memory: 1849.25Mb There were 2 failures: 1) LanguageConverterTest::testGetPreferredVariantUserOption Failed asserting that two strings are equal. --- Expected +++ Actual @@ @@ -tg-latn +tg /home/avar/src/mw/trunk/phase3/maintenance/tests/LanguageConverterTest.php:82 2) Warning No tests found in class ParserUnitTest. FAILURES! Tests: 686, Assertions: 3431, Failures: 2, Incomplete: 34 But when I run phpunit manually on the test then all tests pass: $ phpunit LanguageConverterTest.php PHPUnit 3.4.5 by Sebastian Bergmann. . Time: 23 seconds, Memory: 23.75Mb OK (9 tests, 34 assertions) Also after I get Tests: 686, Assertions: 3431, Failures: 2, Incomplete: 34 in the first output phpunit doesn't exit and continues hugging my memory. Why is it still running? It has already run all the tests. I've worked around this by adding a 'make tap' target which runs the phpunit tests individually with Test::Harness. I made it the default target due to the problems with running all the tests at once with phpunit: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/62071 http://www.mediawiki.org/wiki/Special:Code/MediaWiki/62072 Does something run these tests or the parsertests automatically? It would be really neat to test all svn revisions of MediaWiki and report the results on Special:Code. I think I read somewhere that something runs the parsertests automatically. It's supposed to be running the parser tests and uploading them on commit, but that's been broken for a little while now. What system is this that's running automatic tests on commits? I was investigating setting up a buildbot (http://buildbot.net/) which could have multiple test clients and report tests to IRC/XML which Special:Code could then use. What does the now-broken Special:Code test system use? If we're got a nice standard output from the tests (I think the XML is pretty suited for this), we should be able to upload that result to Code Review. $ prove -j 10 -e 'phpunit --tap' -Q *Test*.php All tests successful. Files=20, Tests=692, 31 wallclock secs ( 0.34 usr 0.21 sys + 18443939634.30 cusr 2803481.20 csys = 18446743116.05 CPU) Result: PASS You can get pretty HTML like this: $ prove --formatter TAP::Formatter::HTML -j 10 -e 'phpunit --tap' -Q *Test*.php ~/www/mw-tap-out.html Which gives you something like this: http://v.nix.is/~avar/mw-tap-out.html That can be parsed with any XML parser that just has to look for td class=results and div id=summary class=passed or div id=summary class=failed ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Version control
On Sat, Feb 6, 2010 at 21:13, Daniel Friesen li...@nadir-seen-fire.com wrote: I believe we've had two discussions in the past on switching to git. I talked to Tim about various other advantages of .git, like the lack of autoprops annoyance, and corrected the notion that there isn't a Windows client and his reponse was maybe in a year or two. Generally the limitation is the fact that we're currently abusing svn's ability to only check out specific directories rather than an entire repo to make it easy to check out all the extensions or individual ones without any trouble. We've had ideas like using git submodules to mark stable versions of extensions so extension repos can be flexibly checked out. Oh something interesting. With a bit of trickery I recently managed to splice the entire history of one git repo into a branch of another git repo creating a git repo that has two separate initial commits in two separate branches. And from the looks of it it's perfectly possible to fetch history from the original repo into the proper branch. So it should be interestingly possible to create a script that fetches history updates for every extension at once by embedding them all into separate branches of a single git repo, and then locally (with no network latency) pulling the history from those branches into the real repos. It's interesting that the #1 con against Git in that document is Lots of annoying Git/Linux fanboys. I guess this is as good a time as any to plug the git-svn notes I scribbled down yesterday: http://www.mediawiki.org/wiki/Git In order to convert to Git it would help to collect a list of things that should be split into separate repositories: * /USERINFO, /civicrm and /wikimedia-web * Everything in /trunk/* * Additionally /trunk/extensions/* and maybe some /trunk/tools/* That should yield around 500 repositories. That might sound crazy but best practice for any distributed version control system is that repositories should be split at the boundaries at which code doesn't pass over, and when's the last time /trunk/FOO shared some code with /trunk/extensions/BAR for instance? And if someone really wants to check out all 430 extensions that's easy enough with an extensions project with 430 submodules, but the most common case should be someone checking out MediaWiki.git + 3-5 extensions. I'm doing some experiments with splitting up MediaWiki's Git mirror[1] using git-filter-branch[2]. It takes a *long* time with this huge repository but a working conversion is the fastest way to get people on board. Of course this is a great chance to clean up some aspects of the repository, such as: * Rewrite the commits to give everyone real names / emails, like Tim Starling / tstarl...@wikimedia.org instead of tstarling. This can be done automatically by parsing the USERINFO files adding to them where appropriate. * Combine users like magnusmanske and magnus_manske into one * Rename/drop branches/tags if someone wants that 1. http://gitorious.org/mediawiki-svn-mirror 2. http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New SVN committer
On Tue, Mar 24, 2009 at 21:45, Chad innocentkil...@gmail.com wrote: Welcome Jan! Just a friendly reminder to commit a USERINFO file :) I added a stub USERINFO for him but I don't know his E-Mail address so I couldn't add that. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] New phpunit tests eat ~1GB of memory
Since the tests were ported from t/ to phpunit's
phase3/maintenance/tests/ in r61938 and other commits running the
tests on my machine takes up to 1GB of memory and grows as it runs
more tests. It seems that phpunit uses the same instance of the php
interpreter for running all the tests.
Is there some way around this? Perhaps phpunit.xml could be tweaked so
that it runs a new php for each test?
Furthermore when I run `make test' I get this:
Time: 03:35, Memory: 1849.25Mb
There were 2 failures:
1) LanguageConverterTest::testGetPreferredVariantUserOption
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-tg-latn
+tg
/home/avar/src/mw/trunk/phase3/maintenance/tests/LanguageConverterTest.php:82
2) Warning
No tests found in class ParserUnitTest.
FAILURES!
Tests: 686, Assertions: 3431, Failures: 2, Incomplete: 34
But when I run phpunit manually on the test then all tests pass:
$ phpunit LanguageConverterTest.php
PHPUnit 3.4.5 by Sebastian Bergmann.
.
Time: 23 seconds, Memory: 23.75Mb
OK (9 tests, 34 assertions)
Also after I get Tests: 686, Assertions: 3431, Failures: 2,
Incomplete: 34 in the first output phpunit doesn't exit and continues
hugging my memory. Why is it still running? It has already run all the
tests.
On Wed, Feb 3, 2010 at 17:35, ia...@svn.wikimedia.org wrote:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/61938
Revision: 61938
Author: ialex
Date: 2010-02-03 17:35:59 + (Wed, 03 Feb 2010)
Log Message:
---
* Port tests from t/inc/
* Added new tests to XmlTest
Added Paths:
---
trunk/phase3/tests/LicensesTest.php
trunk/phase3/tests/SanitizerTest.php
trunk/phase3/tests/TimeAdjustTest.php
trunk/phase3/tests/TitleTest.php
trunk/phase3/tests/XmlTest.php
Added: trunk/phase3/tests/LicensesTest.php
===
--- trunk/phase3/tests/LicensesTest.php (rev 0)
+++ trunk/phase3/tests/LicensesTest.php 2010-02-03 17:35:59 UTC (rev 61938)
@@ -0,0 +1,17 @@
+?php
+
+/**
+ * @group Broken
+ */
+class LicensesTest extends PHPUnit_Framework_TestCase {
+
+ function testLicenses() {
+ $str =
+* Free licenses:
+** GFLD|Debian disagrees
+;
+
+ $lc = new Licenses( $str );
+ $this-assertTrue( is_a( $lc, 'Licenses' ), 'Correct class' );
+ }
+}
\ No newline at end of file
Property changes on: trunk/phase3/tests/LicensesTest.php
___
Added: svn:eol-style
+ native
Added: trunk/phase3/tests/SanitizerTest.php
===
--- trunk/phase3/tests/SanitizerTest.php (rev
0)
+++ trunk/phase3/tests/SanitizerTest.php 2010-02-03 17:35:59 UTC (rev
61938)
@@ -0,0 +1,71 @@
+?php
+
+global $IP;
+require_once( $IP/includes/Sanitizer.php );
+
+class SanitizerTest extends PHPUnit_Framework_TestCase {
+
+ function testDecodeNamedEntities() {
+ $this-assertEquals(
+ \xc3\xa9cole,
+ Sanitizer::decodeCharReferences( 'eacute;cole' ),
+ 'decode named entities'
+ );
+ }
+
+ function testDecodeNumericEntities() {
+ $this-assertEquals(
+ \xc4\x88io bonas dans l'\xc3\xa9cole!,
+ Sanitizer::decodeCharReferences( #x108;io bonas
dans l'#233;cole! ),
+ 'decode numeric entities'
+ );
+ }
+
+ function testDecodeMixedEntities() {
+ $this-assertEquals(
+ \xc4\x88io bonas dans l'\xc3\xa9cole!,
+ Sanitizer::decodeCharReferences( #x108;io bonas
dans l'eacute;cole! ),
+ 'decode mixed numeric/named entities'
+ );
+ }
+
+ function testDecodeMixedComplexEntities() {
+ $this-assertEquals(
+ \xc4\x88io bonas dans l'\xc3\xa9cole! (mais pas
#x108;io dans l'eacute;cole),
+ Sanitizer::decodeCharReferences(
+ #x108;io bonas dans l'eacute;cole! (mais
pas amp;#x108;io dans l'#38;eacute;cole)
+ ),
+ 'decode mixed complex entities'
+ );
+ }
+
+ function testInvalidAmpersand() {
+ $this-assertEquals(
+ 'a b',
+ Sanitizer::decodeCharReferences( 'a b' ),
+ 'Invalid ampersand'
+ );
+ }
+
+ function testInvalidEntities() {
+ $this-assertEquals(
+ 'foo;',
+
Re: [Wikitech-l] Is this the right list to ask questions about parserTests
On Wed, Jul 15, 2009 at 1:24 AM, dan nessettdness...@yahoo.com wrote: Mediawiki powers an awful lot of wikis, some used by businesses that cannot afford instability in its operation. It is in their interest to ensure it remains maintainable. So, they might be willing to provide some funding. In addition I'm sure Mediawiki is used by some parts of the government (both US and other countries), so there might be some funding available through those channels. Lots of people using your software does not translate into funds for you, even if it's mission critical for those users. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Maps-l] How should I generate static OSM maps for Wikimedia with the SlippyMap extension?
On Wed, Jul 15, 2009 at 12:42 AM, Brion Vibberbr...@wikimedia.org wrote: Ævar Arnfjörð Bjarmason wrote: Hello there, long time no see:) In the last few days I've been working on the project of getting OpenStreetMap onto Wikimedia as outlined here: Woohoo! Anyway, one thing standing between us and world domination is rendering those static maps, I'm going to implement this but first I'd like to get comments on *how* we'd like to do it, so I've written a plan for doing it: http://www.mediawiki.org/wiki/Extension:SlippyMap/Static_map_generation I added a couple quickie notes on the talk page... Ah, thanks, to reply to this: Static maps of arbitrary size presumably have much the same problem here as the map tile images. How is it handled there? The same way I want to do static map generation. Just put an arbitrary expiry time on it serve it to the client. It might be good to use a Google Maps Static-like model here; the MediaWiki end can just make itself an img and stick all the relevant info onto the URL, calling out to the static map server. That's a very good idea, but I'd been assuming that I wouldn't be able to do that -- that each apache server was supposed to do things like EasyTimeline generation / image rescaling and likewise static map generation on its own write it to the shared image NFS. But just being able to call out to an existing server makes things a whole lot easier. Then we can just run dedicated rendering machines with the apaches being dumb about all this crazy map stuff. This also means that we can set up the Wikimedia Deutschland servers to do tile rendering and then easily test it on a big wiki (like dewiki) by just enabling the SlippyMap extension which won't do anything more fancy than point static/tile URLs to the external service. So yay! Either storing it on local disk there or simply leaving it to be cached by upper-level squids Throwing it at the squids and making it their problem would be simpler for *me* at least. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] How should I generate static OSM maps for Wikimedia with the SlippyMap extension?
Hello there, long time no see:) In the last few days I've been working on the project of getting OpenStreetMap onto Wikimedia as outlined here: http://techblog.wikimedia.org/2009/04/openstreetmap-maps-will-be-added-to-wikimedia-projects/ Unfortunately I wasn't able to hack on it sooner (but of course other people have been working on it too!) and the project has been somewhat held up by the WM-DE servers being delayed. Anyway, one thing standing between us and world domination is rendering those static maps, I'm going to implement this but first I'd like to get comments on *how* we'd like to do it, so I've written a plan for doing it: http://www.mediawiki.org/wiki/Extension:SlippyMap/Static_map_generation Would generating static images like that be fine for Wikimedia purposes or is this totally crazy? I think it would be just fine, but then again I did write the Cite extension so take that with a grain of salt:) And to spam a bit: if getting pretty OpenStreetMap maps deployed is something you'd like to happen sooner than later head over to our development page: http://www.mediawiki.org/wiki/Extension:SlippyMap#Development I'm working off the Bugzilla tasklist which should be an approximate indication of stuff that needs to be done. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] ANNOUNCE: OpenStreetMap maps will be added to Wikimedia projects
There has been rapid progress on the subject of adding OpenStreetMap maps to Wikimedia projects (e.g. Wikipedia) during the MediaWiki Developer Meet-Up[1] taking place right now in Berlin. We now have a clear plan of action for getting OpenStreetMap maps embedded in Wikimedia wiki (e.g. Wikipedia) pages: * Wikimedia will set up a database to mirror the OSM data (Planet.osm) * Wikimedia will set up its own rendering infrastructure for rendering tiles other maps from the OSM data * The existing MediaWiki extensions for displaying OSM data in a MediaWiki article will be improved to work acceptably in production on Wikimedia servers To prototype all this we'll be using new infrastructure provided by Wikimedia Deutschland[2]. Once things have been tested there they'll eventually be deployed on the main Wikimedia sites. After discussion with the Wikimedia operations people (including Brion Vibber, Mark Bergsma et al) there seem to be no objections to the above plan as long as: * The maps will work not only for JavaScript enabled browsers but also non-JavaScript enabled ones * The tools involved are improved to be relatively stable deployable on Wikimedia, e.g. being able to embed more than one slippy map, the internationalization of error messages etc. * The end product (the generated tiles or map files) are cachable so that they can be thrown at the frontend squids, as they're static images this should be easy. The featureset that we're aiming for to be able to deploy this on Wikimedia sites from the view of the user (more can be added later once we've got it working) is: * The ability to embed OSM maps in articles with something like the Simple image extension[3], perhaps automagically turning into a Slippy Map if the browser supports it * A static or slippy map that can be used by geotagged articles[4] so we can have maps without explicit inclusion of a map tag. We'll also set up a map toolserver for experimenting with other uses of OpenStreetMap data on Wikimedia. People with relevant projects can get access[5] to this toolserver to try out their ideas for tools that could eventually be integrated on the main Wikimedia sites. This project is seeking help from anyone who's interested who'd like to be a part of making this happen, if you want to be a part of adding free maps to the world's largest encyclopedia please subscribe to this mailing list: https://lists.wikimedia.org/mailman/listinfo/maps-l And/or read/edit/comment on the relevant wiki coordination pages: http://meta.wikimedia.org/wiki/OpenStreetMap http://wiki.openstreetmap.org/wiki/Collaboration_with_Wikipedia 1. http://www.mediawiki.org/wiki/Project:Developer_meet-up_2009 2. http://meta.wikimedia.org/wiki/OpenStreetMap#.E2.80.9CMap_Toolserver.E2.80.9D 3. http://wiki.openstreetmap.org/wiki/Simple_image_MediaWiki_Extension 4. http://en.wikipedia.org/wiki/Template:Coord 5. mailto:o...@wikimedia.de ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GitTorrent (pie-in-the-sky post)
On Fri, Dec 5, 2008 at 1:36 PM, Juliano F. Ravasi [EMAIL PROTECTED] wrote: Ironically, the per-file revision control model employed by now-obsolescent VCSes like CVS and RCS would fit Wikipedia better than Git (emphasis on revision control *model*, not software). ...because RCS tracks one file at a time while git tracks whole trees, as you point out. However git's shortcomings when used for a wiki could also be used by having a separate repository for each article. You wouldn't get many of the more interesting git features, and couldn't do `git pull' to update the whole wiki. But it would be interesting to compare one-git/mercurial/whatever-repo-per-article to one-rcs-file-per-article or the current one-article-history-per-article MediaWiki tracks in its database. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
