http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70351 <pre>One of the reasons we want to get the RFC process moving again is that we've got some general agreement that it'll be necessary to do some big refactorings and internal API improvements... yes, we're thinking of seriously going for a MediaWiki 2.0. This is going to mean actually going through and killing some old deprecated interfaces, and possibly a big maintenance/conversion effort on extensions to keep them up to date with internals changes. Some of these changes will be contentious, but necessary for making MediaWiki a better, easier to use, easier to maintain, and easier to extend framework. Having a clearer RFC process should let us discuss these things without falling too much into bikeshedding, and most importantly make sure we come to decisions and actually implement them. Official buy-in from WMF Engineering and from core committers and reviewers is important in making this real -- and I feel like we have it. Over the next few weeks I hope that we'll get through much of the existing RFC backlog,</pre> Brion Vibber 2013-05-26T07:31:18 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70350 <pre> \o/ It may make sense to have a more standardized structure for RFCs. Or at least some better guidance on how to create an RFC. Sometimes people will forget to include background information or a clear statement of the problem and will instead skip straight into proposing solutions. The relationship between an RFC and Bugzilla could also use consideration. For example, I prefer that a mature RFC be attached to a tracking bug in Bugzilla. There seems to be a disagreement about the purpose of RFCs. Some people have suggested that RFCs without a clear execution path and "owner" (i.e., someone committed to implementing the idea) should be avoided. As pointed out in the current architecture guidelines, RFCs encompass ideas that: * someone is hoping others will bring to fruition; or * that currently lack concrete implementation details. I don't see this as an issue. I would simply call these draft RFCs (which the current RFC setup basically does). My concern is that these draft RFCs may be damaged or destro</pre> MZMcBride 2013-05-26T04:11:02 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70349 <pre>Yes, but that is a mistake in the file. That got fixed in Git today. On Sun, May 26, 2013 at 1:29 PM, Jamie Thingelstad &lt;jamie&lt; at &gt;thingelstad.com&gt; wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l&lt; at &gt;lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l</pre> K. Peachey 2013-05-26T03:33:12 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70348 <pre>I just installed this tar ball and Special:Version is reporting 1.21.0rc5. update also reports 'MediaWiki 1.21.0rc5 Updater'. Did the right files get sent up? I downloaded http://download.wikimedia.org/mediawiki/1.21/mediawiki-1.21.0.tar.gz MD5 of file I got is: bbe80b6299ced434aa99acb8866f1886 mediawiki-1.21.0.tar.gz Jamie Thingelstad jamie&lt; at &gt;thingelstad.com mobile: 612-810-3699 find me on AIM Twitter Facebook LinkedIn On May 25, 2013, at 10:20 AM, Mark A. Hershberger &lt;mah&lt; at &gt;everybody.org&gt; wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l&lt; at &gt;lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l</pre> Jamie Thingelstad 2013-05-26T03:29:03 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70347 <pre>Hi, to improve duplicate detection for the Open Access Media Importer, we would like to include redirects in the file namespace, but they do not come up in searches like https://commons.wikimedia.org/w/api.php?action=query&amp;list=search&amp;srnamespace=6&amp;srsearch=pone.0008793.s004&amp;srredirects=1 . For example, http://commons.wikimedia.org/wiki/File:Animal-behavior-pone.0008793.s004.ogv redirects to http://commons.wikimedia.org/wiki/File:A_group_of_50_Drosophila_melanogaster_interacting_in_an_observation_chamber_-_pone.0008793.s004.ogv . Thanks for any pointers. Cheers, Daniel _______________________________________________ Wikitech-l mailing list Wikitech-l&lt; at &gt;lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l</pre> Daniel Mietchen 2013-05-25T20:17:14 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70346 <pre>Thank you for all your work on this Mark, et al! Can’t wait to update tonight! -- Jamie Thingelstad jamie&lt; at &gt;thingelstad.com mobile: 612-810-3699 On May 25, 2013, at 10:20 AM, "Mark A. Hershberger" &lt;mah&lt; at &gt;everybody.org&gt; wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l&lt; at &gt;lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l</pre> Jamie Thingelstad 2013-05-25T17:24:17 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70344 <pre>Hi folks, Many of us met at the Amsterdam Hackathon to discuss architecture guidelines (almost everyone with +2 in MediaWiki core, plus other knowledgeable people), and generally about the need to have more substantive conversations about MediaWiki architecture. It was a really productive discussion, and had a number of outcomes: 1. RFC review: we agreed that RFCs need more diligent review. Brion and Tim are planning to pull together the architects for regular discussions (weekly? TBD) to at least touch all of the outstanding RFCs, with the goal of clearing the current backlog of RFCs. If y'all don't see substantial movement on this in a couple of weeks, please point this out. 2. RFC use: right now, RFCs aren't used in many cases where they should be. Assuming we get into a good flow with RFCs, we can then reasonably expect people to actually write them when they're making significant changes to the MediaWiki architecture. 3. Architecture guidelines: we now have a rough beginning draft of architec</pre> Rob Lanphier 2013-05-25T13:50:04 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70343 <pre>For those of you not at the hackathon, there is one very major result from the meeting that I wanted to publicize. (There are other action items which I'll let other people expand but this one seems most important to me.) If I misunderstood or mis-state something, Robla and others can correct me. Our RFC process has been broken till now. WMF's architecture group has just committed to review and respond to all RFCs by WikiMania. This will probably involve clarifying the process that RFCs are reviewed and providing better documentation for architectural and design direction. I expect there will be more coming out of this meeting, but I wanted to post this note so I would remember to ask Brion about the RFCs he has reviewed next Friday. Mark. </pre> Mark A. Hershberger 2013-05-25T13:10:42 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70342 <pre>I don't know what you mean by "similar program", but of course the Germans have all their local groups, courses, workshops &amp; co. to "train the workforce". For instance https://de.wikipedia.org/wiki/Wikipedia:WikiCon Nemo _______________________________________________ Wikitech-l mailing list Wikitech-l&lt; at &gt;lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l</pre> Federico Leva (Nemo 2013-05-25T08:44:42 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70341 <pre>Indeed, the queue cannot use memcached. Redis will trivialize the time spent on actually queue operations, which could help if that is a bottleneck for job runners. If the actual jobs themselves are slow, of course it won't help too much. Have you already tried setting the job run rate to 0 and is a background script instead? -- View this message in context: http://wikimedia.7.x6.nabble.com/Information-on-MW-and-Redis-tp5005659p5005693.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. _______________________________________________ Wikitech-l mailing list Wikitech-l&lt; at &gt;lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l</pre> Aaron Schulz 2013-05-25T05:44:04 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70340 <pre>I can see how memcached and redis would have similar performance for sessions. Is that also true for job queue? I was assuming that job queue could move from database to redis, but not to memcached. Is that a correct assumption? The main reason I could see moving sessions into redis would be to not manage both redis and memcached, assuming that redis is the key to making the job queue faster. -- Jamie Thingelstad jamie&lt; at &gt;thingelstad.com mobile: 612-810-3699 On May 24, 2013, at 3:07 PM, Aaron Schulz &lt;aschulz4587&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l&lt; at &gt;lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l</pre> Jamie Thingelstad 2013-05-25T00:03:20 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70339 <pre>Note that if you already use memcached for the main cache, there isn't really any reason to switch to redis unless you need replication or persistence. Anyway, to use it for sessions, if you had $wgSessionCacheType explicitly set to something, then you'd need to change that too (like to 'pecl-redis'). In any case, it doesn't hurt to be explicit. This all assumes that $wgSessionsInObjectCache = true as well. -- View this message in context: http://wikimedia.7.x6.nabble.com/Information-on-MW-and-Redis-tp5005659p5005665.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. _______________________________________________ Wikitech-l mailing list Wikitech-l&lt; at &gt;lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l</pre> Aaron Schulz 2013-05-24T20:07:04 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70338 <pre>2.2.2 of the extensions works for me. I downloaded it from source and compiled it. The redis server itself will need to be 2.6 or higher for the job queue. Looking around, I forgot to mention that JobQueueRedis was actually removed from 1.21 (though it's in master and will be in 1.22). -- View this message in context: http://wikimedia.7.x6.nabble.com/Information-on-MW-and-Redis-tp5005659p5005664.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. _______________________________________________ Wikitech-l mailing list Wikitech-l&lt; at &gt;lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l</pre> Aaron Schulz 2013-05-24T20:00:02 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70337 <pre>If you implement this, is there any use for memcached still? I assume PHP also needs to be told that sessions are in redis? Jamie Thingelstad jamie&lt; at &gt;thingelstad.com mobile: 612-810-3699 find me on AIM Twitter Facebook LinkedIn On May 24, 2013, at 2:44 PM, Aaron Schulz &lt;aschulz4587&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l&lt; at &gt;lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l</pre> Jamie Thingelstad 2013-05-24T19:57:08 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70336 <pre>Awesome! Thank you! Do you know the version required for these? Thinking maybe I could writeup a page on mw.o documenting the process of putting redis in place for these. Jamie Thingelstad jamie&lt; at &gt;thingelstad.com mobile: 612-810-3699 find me on AIM Twitter Facebook LinkedIn On May 24, 2013, at 2:44 PM, Aaron Schulz &lt;aschulz4587&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l&lt; at &gt;lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l</pre> Jamie Thingelstad 2013-05-24T19:50:36 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70335 <pre>To use redis as a cache you can have something like: // requires phpredis extension for PHP $wgObjectCaches['pecl-redis'] = array( 'class' =&gt; 'RedisBagOStuff', 'servers' =&gt; array( '127.0.0.1:6379' ), ); $wgMainCacheType = 'pecl-redis'; This would also require that the redis server would have allkeys-lru for its eviction policy in redis.conf. To use redis for a jobqueue, one can have something like: // requires phpredis extension for PHP $wgJobTypeConf['default'] = array( 'class' =&gt; 'JobQueueRedis', 'redisServer' =&gt; '127.0.0.1:6379', 'redisConfig' =&gt; array(), 'claimTTL' =&gt; 3600 ); This works best if the redis server uses rdb snapshots and/or append-only-file logging in redis.conf so that jobs are lost with power outages or restarts. -- View this message in context: http://wikimedia.7.x6.nabble.com/Information-on-MW-and-Redis-tp5005659p5005660.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. _______________________________________________ Wikitec</pre> Aaron Schulz 2013-05-24T19:44:58 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70334 <pre>Hello all, I keep seeing references in WMF documents to using Redis for session storage and as the storage for the job queue going forward. However, LocalSettings doesn't have any references to Redis. It looks like the session changes for Redis were in 1.20, and I thought that the change for the job queue to be backed by Redis was coming in 1.21. It also seems that Notifications (Echo) may require Redis, but that's not real clear. I'm wondering what the general status of this is? As a 3rd party mediawiki admin, I'm eager to get redis going primarily for the job queue improvements, but with nothing noted in local settings documentation I'm wondering what the plan is for these redis based features? Will $wgMainCacheType be getting a CACHE_REDIS option? Jamie Thingelstad jamie&lt; at &gt;thingelstad.com mobile: 612-810-3699 find me on AIM Twitter Facebook LinkedIn _______________________________________________ Wikitech-l mailing list Wikitech-l&lt; at &gt;lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech</pre> Jamie Thingelstad 2013-05-24T19:39:23 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70333 <pre> The Gerrit for this is https://gerrit.wikimedia.org/r/#/c/61987/ Matt Flaschen _______________________________________________ Wikitech-l mailing list Wikitech-l&lt; at &gt;lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l</pre> Matthew Flaschen 2013-05-24T19:37:57 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70332 <pre> I'd be in and available, if somebody defines a room &amp; time for it. (I'm also in for any Bugzilla or bug report questions in general.) andre </pre> Andre Klapper 2013-05-24T14:25:54 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70331 <pre>awesome! On Thu, May 9, 2013 at 11:42 PM, Chad &lt;innocentkiller&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l&lt; at &gt;lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l</pre> Martijn Hoekstra 2013-05-24T11:36:48 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/70330 <pre>Hello! I have implemented an idea for WikiEditor extension: replace "step-by-step publish" feature with another one - "publish staying in edit mode via AJAX". You can see a demo at http://wiki.4intra.net/ if you want. It works simply by sending an API save article request while NOT closing the article being edited. Also it handles section edits correctly via re-requesting section content after editing, so you'll stay with consistent edit form even if you add sections. The idea is to give authors the ability to save intermediate results. My question is - does anyone really need "step-by-step publishing" feature that is in WikiEditor? I think it's useless because it just duplicates the existing functionality, just submits the form using normal POST request, and makes editing harder as you have to do more clicks. I would submit a patch to Gerrit if you're interested in replacing it with "publish-staying-in-editmode". </pre> vitalif< at >yourcmc.ru 2013-05-24T11:26:20 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.science.linguistics.wikipedia.technical