Re: [Wikitech-l] ResourceLoader Debug Mode
On 30/09/10 08:27, Trevor Parscal wrote: > There seems to be some confusion about how ResourceLoader works, which > has been leading people to make commits like r73196 and report bugs like > #25362. I would like to offer some clarification. I made that change because it was requested by multiple people in discussions before the resource loader was implemented. It's not because I actually had any actual problem with debugging, I'm well aware of the existence of the debug mode. Concerns were raised that it may be necessary to interpret minified code in cases such as: * Where it is suspected that, due to caching issues, the debug code may not be the same as the minified code. * To debug the minifier itself, which is far short of a full JavaScript parser and may well introduce functional differences. * Where end users report platform-specific JavaScript errors, it may be useful to be able to match the line number of the error with something meaningful. Since the cost of adding line breaks is fairly small, the contention was that it was a fair compromise between size and developer (and tech supporter) sanity. So I took those comments on board and implemented it shortly after the branch merge. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader Debug Mode
Trevor Parscal wrote: > That is all in our roadmap - which needs to be updated and put onto > the wiki. Ideally this will happen next week when Alolita returns from > Paris. Awesome. Looking forward to it. :-) MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader Debug Mode
That is all in our roadmap - which needs to be updated and put onto the wiki. Ideally this will happen next week when Alolita returns from Paris. - Trevor On 9/29/10 4:27 PM, MZMcBride wrote: > Trevor Parscal wrote: >> ResourceLoader, if you aren't already aware, is a new system in >> MediaWiki 1.17 which allows developers to bundle collections of >> *resources* (like JavaScript and CSS files, or localized messages) into >> *modules*. Modules may represent any number of scripts, styles and >> messages, which are read from the file system, the database, or >> generated by software. > Speaking of debugging and breakages... is there an audit page anywhere > currently for what ResourceLoader has broken? Ideally a page with a specific > look at extensions that Wikimedia uses. Something like, "Wikimedia has X > extensions installed. Of these, the following are currently broken with > ResourceLoader" > > I looked at http://www.mediawiki.org/wiki/ResourceLoader and didn't see > anything off-hand. Could/Should something like this be made? I've heard a > lot of rumors about various extensions being broken (FlaggedRevs, e.g.), but > I don't know what the current status is (whether these problems have been > addressed, whether there are other extensions that are broken, whether this > particular rumor turned out to not be true). > > Thanks! > > MZMcBride > > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Drafting the upcoming engineering overview
Ryan Lane wrote: > We use etherpad for real-time note taking, as it is better suited to > that than MediaWiki is. For most of the projects that I am a part of, > after the meeting we move the notes from etherpad to a wiki, usually > mediawiki.org. I don't believe any of us think etherpad is a good way > to keep documents for any period of time, since it is impossible to > find anything in it. I'm betting that almost everything not moved from > etherpad is never looked at again. > > I think the correct solution here is to continue to move the documents > from etherpad to mediawiki.org (or some other appropriate wiki), and > try to be more vigilant about doing so. I've tried to centralize and standardize the meetings notes here: http://www.mediawiki.org/wiki/Meetings MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader Debug Mode
Trevor Parscal wrote: > ResourceLoader, if you aren't already aware, is a new system in > MediaWiki 1.17 which allows developers to bundle collections of > *resources* (like JavaScript and CSS files, or localized messages) into > *modules*. Modules may represent any number of scripts, styles and > messages, which are read from the file system, the database, or > generated by software. Speaking of debugging and breakages... is there an audit page anywhere currently for what ResourceLoader has broken? Ideally a page with a specific look at extensions that Wikimedia uses. Something like, "Wikimedia has X extensions installed. Of these, the following are currently broken with ResourceLoader" I looked at http://www.mediawiki.org/wiki/ResourceLoader and didn't see anything off-hand. Could/Should something like this be made? I've heard a lot of rumors about various extensions being broken (FlaggedRevs, e.g.), but I don't know what the current status is (whether these problems have been addressed, whether there are other extensions that are broken, whether this particular rumor turned out to not be true). Thanks! MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Drafting the upcoming engineering overview
David Gerard wrote: > If there's something on the tech blog that you think warrants wider reading, > pinging Jay's office is probably the first thing to do, for a paragraph > linking to the tech blog post. I've replied to this comment and others here: http://meta.wikimedia.org/w/index.php?oldid=2139159 I hope you'll join the conversation there. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Drafting the upcoming engineering overview
Rob Lanphier wrote: > On Tue, Sep 28, 2010 at 8:43 PM, MZMcBride wrote: >> (I >> don't completely understand why Wikimedia needs two blogs, but that's a >> matter for a different day.) > > It probably doesn't hurt to have a place for us to nerd out and not > have to worry about writing for a general audience. It seems that > occasionally having some sort of "best of the techblog"-type summary > posting on the main blog would be a good thing to do, but that means > someone would have to decide what "best" is, and then write about it, > so it's probably not something that will happen soon. In order to avoid thread drift, I've replied to this here: http://meta.wikimedia.org/w/index.php?oldid=2139159 I hope you'll join the conversation there. It would probably also be prudent to poke Jay about this as well. >> There's been no activity on that page since September 23 (a few hours after >> this thread was started). It's nearly October 1. To me, that indicates a >> problem. > > Funny story there. Most of us EPMs here have been talking daily about > wanting to make sure we have some prose in place before our drafting > session tomorrow, the same way people talk about losing weight or > cleaning out their garage. That's the bad news. The good news is > that we have scheduled a drafting session tomorrow that we'll be > hammering out a draft. When writing on a wiki, you would (or should, I guess) always link acronyms and initialisms. In a mailing list post, this isn't possible, so it's really best to write out the full word. I never remember what "EPM" stands for. http://www.mediawiki.org/wiki/EPM or http://meta.wikimedia.org/wiki/EPM or http://wikimediafoundation.org/wiki/EPM ... ought to be a redirect to a description of what an EPM is, who fills these roles, etc. >> Wikimedia has been having weekly (or fortnightly) status meetings about most >> of the items you listed on MediaWiki.org, but the notes are being held on >> Wikimedia's installation of EtherPad. Either document this EtherPad >> installation (I'm not even sure if the URL is supposed to be public, so I'll >> omit it here) or stop using it and post all of the notes directly on >> MediaWiki.org. These notes in EtherPad are (by far) the most up-to-date and >> helpful pages for tracking the status of projects that I've seen, but I >> doubt more than a dozen people outside of Wikimedia Foundation staff have >> any idea they exist. Though, perhaps a bit ironically, I haven't seen (m)any >> ops-related notes on EtherPad, as far as I remember, so that still might be >> an area in which only one or two people can give an accurate update. > > I think our dream tool would be EtherPad realtime capabilities built > into MediaWiki. I have a lot of dreams as well. I think it makes a lot more sense to work within the current reality, though. :-) I think some of the EtherPad notes were transferred to MediaWiki.org today. This is definitely a step in the right direction. If there's a way to ensure that this happens regularly, that would be awesome. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader Debug Mode
It's not a matter of performance, it's a matter of complexity. More configurable does not always mean better. - Trevor On 9/29/10 3:46 PM, Maciej Jaros wrote: >Trevor Parscal wrote: >> There seems to be some confusion about how ResourceLoader works, which >> has been leading people to make commits like r73196 and report bugs like >> #25362. I would like to offer some clarification. >> >> ResourceLoader, if you aren't already aware, is a new system in >> MediaWiki 1.17 which allows developers to bundle collections of >> *resources* (like JavaScript and CSS files, or localized messages) into >> *modules*. Modules may represent any number of scripts, styles and >> messages, which are read from the file system, the database, or >> generated by software. >> >> When a request is made for one or more modules, each resource is >> packaged together and sent back to the client as a response. The way in >> which these requests and responses are performed depends on whether >> debug is on or off. >> >> When debug mode is off: >> >> * Modules are requested in batches >> * Resources are combined into modules >> * Modules are combined into a response >> * The response is minified >> >> When debug mode is on: >> >> * Modules are requested individually >> * Resources are combined into modules >> >> I think it's debatable whether debug=true mode goes far enough, since it >> still combines resources into modules, and I am open to contributions >> that can make debug=true mode even more debugging friendly by delivering >> the resources to the client as unchanged as possible. I also think it's >> debatable if debug=false mode goes far enough, since things like Google >> Closure Compiler have been proven to even further reduce the size of >> JavaScript resources, so I am also open to contributions which can make >> debug=false even more production friendly by improving front-end >> performance. > I might be a little tired but are you saying that debug mode does not > preserve original line numbers? So this is debug mode as in "a bit > easier to debug in Firebug then fully minified code"? > > And I still don't see how minification options are evil. One "if" won't > really change performance. > > Regards, > Nux. > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader Debug Mode
Maciej Jaros wrote: > I might be a little tired but are you saying that debug mode does not > preserve original line numbers? So this is debug mode as in "a bit > easier to debug in Firebug then fully minified code"? > > And I still don't see how minification options are evil. One "if" won't > really change performance. > > Regards, > Nux. No. The files are served 'as is' in debug mode. What he says is "Do not try to keep line numbers in minified mode (use debug mode instead)". ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader Debug Mode
Trevor Parscal wrote: >There seems to be some confusion about how ResourceLoader works, which > has been leading people to make commits like r73196 and report bugs like > #25362. I would like to offer some clarification. > > ResourceLoader, if you aren't already aware, is a new system in > MediaWiki 1.17 which allows developers to bundle collections of > *resources* (like JavaScript and CSS files, or localized messages) into > *modules*. Modules may represent any number of scripts, styles and > messages, which are read from the file system, the database, or > generated by software. > > When a request is made for one or more modules, each resource is > packaged together and sent back to the client as a response. The way in > which these requests and responses are performed depends on whether > debug is on or off. > > When debug mode is off: > > * Modules are requested in batches > * Resources are combined into modules > * Modules are combined into a response > * The response is minified > > When debug mode is on: > > * Modules are requested individually > * Resources are combined into modules > > I think it's debatable whether debug=true mode goes far enough, since it > still combines resources into modules, and I am open to contributions > that can make debug=true mode even more debugging friendly by delivering > the resources to the client as unchanged as possible. I also think it's > debatable if debug=false mode goes far enough, since things like Google > Closure Compiler have been proven to even further reduce the size of > JavaScript resources, so I am also open to contributions which can make > debug=false even more production friendly by improving front-end > performance. I might be a little tired but are you saying that debug mode does not preserve original line numbers? So this is debug mode as in "a bit easier to debug in Firebug then fully minified code"? And I still don't see how minification options are evil. One "if" won't really change performance. Regards, Nux. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] ResourceLoader Debug Mode
There seems to be some confusion about how ResourceLoader works, which has been leading people to make commits like r73196 and report bugs like #25362. I would like to offer some clarification. ResourceLoader, if you aren't already aware, is a new system in MediaWiki 1.17 which allows developers to bundle collections of *resources* (like JavaScript and CSS files, or localized messages) into *modules*. Modules may represent any number of scripts, styles and messages, which are read from the file system, the database, or generated by software. When a request is made for one or more modules, each resource is packaged together and sent back to the client as a response. The way in which these requests and responses are performed depends on whether debug is on or off. When debug mode is off: * Modules are requested in batches * Resources are combined into modules * Modules are combined into a response * The response is minified When debug mode is on: * Modules are requested individually * Resources are combined into modules I think it's debatable whether debug=true mode goes far enough, since it still combines resources into modules, and I am open to contributions that can make debug=true mode even more debugging friendly by delivering the resources to the client as unchanged as possible. I also think it's debatable if debug=false mode goes far enough, since things like Google Closure Compiler have been proven to even further reduce the size of JavaScript resources, so I am also open to contributions which can make debug=false even more production friendly by improving front-end performance. The commits and bugs that I'm contending here are ones which are aiming to dilute the optimized nature of debug=false mode, when debug=true mode is really what they should be using or improving. These kinds of changes and suggestions result in software that is neither optimized for debugging or for production, making the front-end performance of the site in production slower without making it any easier to debug than it would have been by using debug=true. If you are a developer, working on your localhost, you probably want to code with... $wgResourceLoaderDebug = true; .. and then test that things work in debug=false mode before committing your code. This will result in more requests but less processing, which will be much faster when developing on localhost. I hope this helps clarify this situation. - Trevor ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Drafting the upcoming engineering overview
Hoi, Not only more posts are more then welcome but also more illustrations.. Get the message out, do not be an oyster, show what you are on about !! Thanks, GerardM On 29 September 2010 23:13, David Gerard wrote: > On 29 September 2010 17:08, David Gerard wrote: > > On 29 September 2010 06:51, Rob Lanphier wrote: > >> On Tue, Sep 28, 2010 at 8:43 PM, MZMcBride wrote: > > > >>> (I > >>> don't completely understand why Wikimedia needs two blogs, but that's a > >>> matter for a different day.) > > > >> It probably doesn't hurt to have a place for us to nerd out and not > >> have to worry about writing for a general audience. It seems that > >> occasionally having some sort of "best of the techblog"-type summary > >> posting on the main blog would be a good thing to do, but that means > >> someone would have to decide what "best" is, and then write about it, > >> so it's probably not something that will happen soon. > > > > > > The > > ... main blog is Jay Walsh and the comcom's thing. The tech blog runs > independently of him. > > If there's something on the tech blog that you think warrants wider > reading, pinging Jay's office is probably the first thing to do, for a > paragraph linking to the tech blog post. Anyone feeling inspired can > do this. Or, indeed, suggest a main blog post. > > (Personally I think the main blog should have posts much more > frequently, but it's not mine ;-) > > > - d. > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Changes in ResourceLoader
I have also now added documentation (which reflects this change) to: http://www.mediawiki.org/wiki/Manual:Hooks/ResourceLoaderRegisterModules - Trevor On 9/29/10 12:25 PM, Trevor Parscal wrote: >As of r73971 ResourceLoader no longer works like a global static > object. This affects a bunch of internals, but more to the point of this > message, this affects the hook that some of you have started making use > of: "ResourceLoaderRegisterModules". > > Instead of using ResourceLoader::register() within your hook, now you > will need to accept&$resourceLoader as an argument and call > $resourceLoader->register(). > > The documentation in docs/hooks.txt has been updated in r73972 to > reflect this change. > > - Trevor > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Changes in ResourceLoader
As of r73971 ResourceLoader no longer works like a global static object. This affects a bunch of internals, but more to the point of this message, this affects the hook that some of you have started making use of: "ResourceLoaderRegisterModules". Instead of using ResourceLoader::register() within your hook, now you will need to accept &$resourceLoader as an argument and call $resourceLoader->register(). The documentation in docs/hooks.txt has been updated in r73972 to reflect this change. - Trevor ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] using parserTests code for selenium test framework
Hi, since the wiki under test is not neccessarily the wiki running the test, it might be useful to visualize that (I have numbered the individual steps to make reference to them easier in the discussion): testrunner wiki under test -- --- 1.1 start selenium which in turn starts a browser to talk to the wiki under test 1.2 send request for new test with unique test id and tests that will be fired 2.1 create cookie with test id 2.2 create temporal resources according to tests list 2.3 create test tracker with timestamp 2.4 return success code 3.1 start testsuites via selenium 3.2 send a lot of individual requests according to the tests 4.1 testrunner is identified by test id 4.2 reconfigure database and resources according to test id 4.3 ? Do something with memcached ? 4.4 execute request 4.5 update timestamp in test tracker 5.1 send a teardown request 6.1 execute teardown, i.e. delete all resources associated with test id 6.2 delete test tracker 6.3 return success code 7.1 stop selenium Now, if something breaks during the test, the test tracker will not be deleted and can serve as as basis for a cleanup procedure that is triggered by a cronjob. Is this something we can all agree on? I assume, steps 2.2 (setting up temporary test data) and 4.2 (find a mechanism to actually use the test data) will be the ones we have to work on now. Regards, Markus -Ursprüngliche Nachricht- Von: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Ryan Lane Gesendet: Freitag, 24. September 2010 20:22 An: Wikimedia developers Betreff: Re: [Wikitech-l] using parserTests code for selenium test framework > Here is all that is required: > * a single wildcard entry in Apache configuration > * one or two lines in LocalSettings.php to pull a DB name from the > hostname/path/CLI parameters. > > As for cleaning up resources to keep the machine from getting clogged, > it's very unlikely that your test wikis will fill up a > multi-hundred-gigabyte drive in the middle of a run. If you find that > they do, there's still no need to tie cleanup of any particular run to > any particular other run. > > All you need to know is which runs have completed and can now be cleaned up. > I'd like to add some ideas to this thread that were discussed in the Selenium meeting this morning. The basic plan we discussed (and I'm sure I'll be corrected some on this) is as follows: When a run begins, it registers itself with the wiki and gets a session back. The wiki software, on creating the session, makes a new run specific wiki using the wiki family method. The test will pass both the session cookie, and a test type cookie, which will dynamically configure the wiki as the tests run. When the run is complete, it should notify the wiki that the test run is complete. The wiki software will then destroy the session and the dynamically created resources. If a run doesn't complete for some reason, a cron can clean up resources that haven't been used in some appropriate amount of time. Respectfully, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Office Hours Session on the MediaWiki Developer Documentation
Greetings All, My name is Zak Greant. For the last few months, I've been working as a contractor for the WikiMedia Foundation. My focus is on improving the MediaWiki developer documentation and the processes around it. Later today, I will be running an IRC office hours session [0] to talk about what I've been working on and to find out what people would like to see from me. The session will be quite informal – I'll provide a bit of background on what I've been doing and why I've been doing it, and I'm hoping that participants will share the issues and ideas that they have about the developer documentation with me. The session is scheduled for 04:00 to 05:00 UTC on Thursday. For some of us (myself included) the session will be on Wednesday night. See the list below to find the time of the session relative to a city near year. If you'd like to prepare for the session, reading the log from the past session (which I neglected to promote) will help get you up to speed: http://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2010-09-29 I hope that many of you can make it! ==Local Times== San Fran. Wed 21:00 - 22:00 New YorkThu 00:00 - 01:00 London Thu 05:00 - 06:00 BernThu 06:00 - 07:00 New Delhi Thu 09:30 - 10:30 Beijing Thu 12:00 - 13:00 Tokyo Thu 13:00 - 14:00 CanberraThu 14:00 - 15:00 [0] As per http://meta.wikimedia.org/wiki/IRC_office_hours -- Zak Greant (Wikimedia Foundation Contractor) Plans, reports + logs at http://mediawiki.org/wiki/User:Zakgreant Want to talk about the Mediawiki developer docs? Catch me on irc://irc.freenode.net#wikimedia-office Wed. from 16:00-18:00 UTC & Thu. from 04:00-06:00 UTC ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Drafting the upcoming engineering overview
On 29 September 2010 17:08, David Gerard wrote: > On 29 September 2010 06:51, Rob Lanphier wrote: >> On Tue, Sep 28, 2010 at 8:43 PM, MZMcBride wrote: > >>> (I >>> don't completely understand why Wikimedia needs two blogs, but that's a >>> matter for a different day.) > >> It probably doesn't hurt to have a place for us to nerd out and not >> have to worry about writing for a general audience. It seems that >> occasionally having some sort of "best of the techblog"-type summary >> posting on the main blog would be a good thing to do, but that means >> someone would have to decide what "best" is, and then write about it, >> so it's probably not something that will happen soon. > > > The ... main blog is Jay Walsh and the comcom's thing. The tech blog runs independently of him. If there's something on the tech blog that you think warrants wider reading, pinging Jay's office is probably the first thing to do, for a paragraph linking to the tech blog post. Anyone feeling inspired can do this. Or, indeed, suggest a main blog post. (Personally I think the main blog should have posts much more frequently, but it's not mine ;-) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Drafting the upcoming engineering overview
On 29 September 2010 06:51, Rob Lanphier wrote: > On Tue, Sep 28, 2010 at 8:43 PM, MZMcBride wrote: >> (I >> don't completely understand why Wikimedia needs two blogs, but that's a >> matter for a different day.) > It probably doesn't hurt to have a place for us to nerd out and not > have to worry about writing for a general audience. It seems that > occasionally having some sort of "best of the techblog"-type summary > posting on the main blog would be a good thing to do, but that means > someone would have to decide what "best" is, and then write about it, > so it's probably not something that will happen soon. The ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [openZIM dev-l] [STRASBOURG, 16/17 September] Next developer Meeting
Dear all, Emmanuel has organised our 3rd openZIM Developers Meeting in Strasbourg: We will meet on October 15th in the evening at: Hotel PAX 24-36 rue du Faubourg National 6700 Strasbourg, Alsace OpenStreetMap: http://www.openstreetmap.org/export/embed.html?bbox=7.73142,48.58123,7.7396,48.58679&layer=mapnik&marker=48.58244,7.73660 The Hotel provides us with accommodation, breakfast, coffee breaks, meeting room, video projector, flipchart and lunch until Sunday evening. Dinner for Friday and Saturday will be organised spontaneously on-site. Costs for all this is covered with our openZIM budget sponsored by Wikimedia CH, only travel costs cannot be covered. Please register on the wiki if not yet as Emmanuel has already booked the rooms of those who already registered, so he knows soon how many additional rooms need to be booked. http://openzim.org/Developer_Meetings/2010-2 Please also have a look at the agenda and add whatever you miss. See you soon in Strasbourg! Manuel -- Regards Manuel Schneider Wikimedia CH - Verein zur Förderung Freien Wissens Wikimedia CH - Association for the advancement of free knowledge www.wikimedia.ch ___ dev-l mailing list de...@openzim.org https://intern.openzim.org/mailman/listinfo/dev-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Balancing MediaWiki Core/Extensions
On Wed, Sep 29, 2010 at 3:01 AM, Ryan Lane wrote: > > If we don't plan on doing one of two things, then we are forcing our > users into the crapshoot that is finding the correct extension > version, or possibly running insecure or buggy extensions. > Like we are doing today. So yes, indeed something that we should fix. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
