[Wikitech-l] New mediawiki.page_change.v1 event stream publicly available
The Wikimedia Data Engineering team is pleased to announce that a new event stream, mediawiki.page_change.v1, is now publicly available at stream.wikimedia.org (here <https://stream.wikimedia.org/v2/ui/#/?streams=mediawiki.page_change.v1>). The new event stream models page changes using a consolidated changelog data model, whereas existing streams, like page-create and revision-create, model each type of page change as a separate stream. With the current model, you would have to consume multiple streams to understand how a MediaWiki page changed. With the new stream, when a page is created, edited, or deleted, an event captures the new state, as well as the state prior to the change. For more information on what fields you can expect to see in the events, see the schema definition here <https://schema.wikimedia.org/repositories//primary/jsonschema/mediawiki/page/change/latest.yaml> . Starting now, new streams will be suffixed with a major version and will not use hyphens in stream names. For more information, see here <https://wikitech.wikimedia.org/wiki/Event_Platform/Stream_Configuration#Stream_versioning> . Benefits: - Only one stream to consume (instead of having to consume page-create, page-delete, and revision-create streams to have a full picture of page changes) - Events are ordered for a given page_id (delete will not come before create) - Latest event has current and prior state The existing event streams, such as page-create, revision-create, page-delete, etc will continue to remain available, for now. We encourage people to migrate to the new consolidated stream when they can as we plan to mark the existing streams as deprecated within the next year. We will send another communication about this when the plan is decided. If you have any questions or issues please drop a Phabricator ticket here <https://phabricator.wikimedia.org/project/board/6628/> -- Luke Bowmaker Data Engineering - Product Manager ___ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
[Wikitech-l] Privilege request
Hi, I'm not entirely sure what to write here, but I believe "bringing up" Privilege requests on Gerrit on this mailing list is required, so I'm emailing to do just that, bring up my privilege request for the "Sudo" extension, which can be found here: https://phabricator.wikimedia.org/T318196 Thanks in advance, Original Authority (OAuthority on Phab) ___ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
[Wikitech-l] (no subject)
___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Fwd: [Translators-l] Purodha passed away
Would be a nice idea, John. Sadly there isn't a way yet, to make a query for tokens (At least I didn't find one). For people who want to leave a last message to him, we got a condolence list at dewiki: https://de.wikipedia.org/wiki/Benutzer:Purodha/Kondolenzliste -- Luke Am 03.09.2016 um 02:21 schrieb jay...@gmail.com: On Sat, 3 Sep 2016 02:43 Amir E. Aharoni, <amir.ahar...@mail.huji.ac.il> wrote: This is very sad. He was not only a prolific translator, but a prolific bug reporter, too. May he rest in peace. Indeed. Also developed patches. His activity can be seen here: https://phabricator.wikimedia.org/p/Purodha/ Can we find the open bugs he voted for/awarded tokens to? And do the hardest one in his honour? -- John ___ 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] question about wikimedia apache module mod_pagespeed
Hello, it's possible to add the Google Page Speed module on the wikipedia apache ? For speed purpose. I want to discuss with you of this possibility. Thanks Luke ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] category intersection conversations
Without deliberately making it an even longer term plan, as I think it is a great idea, another long goal solution to the same problem would be (as Flow gets Wikipedians into the idea of tagging) that categories get largely replaced by tags. That way they lose much of their absoluteness and therefore some of their controversy. Categories are hard for Wikipedia because compromise is not possible. Consensus can be reached on a subtly different compromise version of the wording of a sentence or paragraph, but there is no compromise on categories. A category either exists or does not. A page either goes in or does not. With tags, a biography could relatively uncontroversially be tagged as Novelist, Woman, Best Selling, American, Blonde Haired, Enjoys Spicy Food even if nearly everybody agrees that half the tags while true are entirely unimportant and not relevant to the subject's area of notability. Whether some tags like race and appearance should exist at all may still generate debate, but if they are only ever available modifiers and not hard categories their offense would be softened. For some subjects, entirely uncontroversial tags could be extracted from Wikidata. It would be content shakeup and therefore perhaps politically difficult, but it would take a lot of the technical challenge out of joins, even permitting joins (automatically or manually) with tags translated into equivalent versions in other languages. All possible combinations of tag derived categories would then exist, and it would just be a matter of debate as to whether there is a justification to add a link from a page to Biography+Novelist+Enjoys Spicy Food or if that is a meaningless category. If reverted, the one person interested in that exact category could still always visit it, it's just that other users would not be directed to it unless they probe talk page debates. Luke Welling On Thu, May 9, 2013 at 12:38 PM, James Forrester jforres...@wikimedia.orgwrote: [I worry we're talking about operational details, which should be a wider discussion, rather than a technology/feasibility conversation to which this list is more suited. Perhaps moving this on-wiki would be best?] On 9 May 2013 09:28, Brad Jorsch bjor...@wikimedia.org wrote: On Wed, May 8, 2013 at 10:47 PM, James Forrester jforres...@wikimedia.org wrote: * Pages are implicitly in the parent categories of their explicit categories * - Pages in Politicians from the Netherlands are in People from the Netherlands by profession (its first parent) and People from the Netherlands (its first parent's parent) and Politicians (its second parent) and People (its second parent's parent) and … * - Yes, this poses issues given the sometimes cyclic nature of categories' hierarchies, but this is relatively trivial to code around Category cycles are the least of it. The fact that the existing category hierarchy isn't based on any sensible-for-inference ontology is a bigger problem. Let's consider what would happen to one of my favorite examples on enwiki: * The article for Romania is in Black Sea countries. Ok. * And that category is in Black Sea, so Romania is in that too. Which is a little strange, but not too bad. * And Black Sea is in Seas of Russia and Landforms of Ukraine. Huh? Romania doesn't belong in either of those, despite that being equivalent to your example where pages in Politicians from the Netherlands also end up in People via Politicians. And it gets worse the further up you go. You would have Romania in Liquids a few more levels up. For this to work, each wiki would have to redo its category hierarchy as a real ontology based on is-a relationships, rather than the current is-somehow-related-to. Or we would have to introduce some magic word or something to tell MediaWiki that Politicians is-a People is a valid inference while Black Sea countries is-a Black Sea isn't. In other words, code-wise adding tags to an article is the same as categories with inference and querying. But trying to use the existing category setup as it exists on something like enwiki as tags for inference (or querying, to a lesser extent) seems like GIGO. Quite - the bit of my proposal where the categories would get created on Wikidata from scratch as a synthesis of the needs of the editing community. :-) Implicitly, these would have clear semantics about the correctitude of their usage governed by something analogous to how Wikidata's community are managing the roll-out of statements on the system. In terms of tools to prevent this becoming an issue, Wikidata's nature means we could easily make sure that the domain of a category would be limited (e.g. Fluids maps to substances, not instances of substances). * Readers can search, querying across categories regardless of whether they're implicit or explicit * - A search for the intersection of People from the Netherlands
Re: [Wikitech-l] Gerrit actively discourages discussion
For my own changes I have a workflow that's a little clunky, but works for me. I'll comment or mark done on every comment, so if I see the same number of drafts as comments, I know I've addressed them all. The workflow I have not found is a way to efficiently re-review other people's changes that I've previously reviewed. It takes a lot of time to properly review a big change, and I don't know an easy way to say Show me all my comments on previous patch sets so I can see if they have been addressed. Luke Welling On Tue, Apr 2, 2013 at 9:10 AM, Chad innocentkil...@gmail.com wrote: On Tue, Apr 2, 2013 at 9:03 AM, MZMcBride z...@mzmcbride.com wrote: Would it be possible to have Gerrit import a JavaScript page from MediaWiki.org (e.g., MediaWiki:Gerrit.js)? This might allow dedicated users to override some of the default behavior (such as the block-level comment auto-collapsing) or add new functionality (such as a reply link similar to Bugzilla's). There's functionality to write custom Javascript and inject it within Gerrit. So yes, we could easily have our own JS that overrides default behavior here. I wouldn't feel entirely comfortable fetching it from MediaWiki.org on the fly--but we can host the code within Gerrit. -Chad ___ 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] job queue
You probably want to run those jobs via maintenance/runJobs.php that way you can have more control over when and where they get run. You can control the type of jobs that get run, so you can effectively create priority specific behavior or at least move expensive jobs onto machines that won't slow the rest of your processing. Luke Welling On Mon, Mar 25, 2013 at 12:34 PM, dan entous d_ent...@yahoo.com wrote: context --- i’m working on a mediawiki extension, http://www.mediawiki.org/wiki/Extension:GWToolset, which has as one of its goals, the ability to upload media files to a wiki. the extension, among other tasks, will process an xml file that has a list of urls to media files and upload those media files to the wiki. our ideal goal is to have this extension run on http://commons.wikimedia.org/. job queue goals --- 1. setup the processing of the xml file as a job queue job 2. each media file upload to be setup as a job queue job current implementation -- i have been able to achieve goal 2 and will sort out goal 1 shortly. issues/questions 1. each of these jobs can take several seconds to complete. i have noticed in my local wiki that each of these jobs is picked up with each wiki visit and slows down the response of the wiki by however many seconds the job takes to run, a sleep in the job shows that if the job takes 15 seconds to run the wiki will be slowed down by that amount of time; i don't want this to happen on my local wiki or on commons. a. are jobs on commons run as part of each wiki visit? b. is there a cron job that takes care of the job queue on commons instead of using each wiki visit? c. if not, is there a way to indicate that the job should only be run as a cron job and not with a wiki visit? 2. if there's no solution to running the job with each wiki visit and slowing down the site, what other suggestions are there on processing the xml file and individual media file uploads? thanks in advance! dan ___ 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] Gerrit Wars™: a strategy-guide
Ori's advice rings true with me. It's something I need to get better at. On the email titiel sidetrack, it should not create a 4th way. Without verifying them those all look like valid representations of the same data. MIME encoded word syntax only has two possible encodings, quoted printable and base 64. The one with the Q after UTF-8 should be the quoted printable version. The one with the B after UTF-8 has been encoded as base64 instead. Of course it's possible somebody's client or MTA has munged them but the point of encoded word is that even if you only speak RFC2822 and not RFC2047(?) you can still transmit them correctly. Luke Welling On Thu, Mar 21, 2013 at 11:19 AM, Mark A. Hershberger m...@everybody.orgwrote: On 03/20/2013 10:43 AM, Jasper Wallace wrote: On Tue, 19 Mar 2013, MZMcBride wrote: P.S. mailman: there's a non-ASCII character in the subject line. Attack! Why? It's correctly encoded: Because the way the subject line is displayed 3 different ways on the archive page: http://lists.wikimedia.org/pipermail/wikitech-l/2013-March/thread.html#67742 There we have: Gerrit =?utf-8?Q?Wars=E2=84=A2=3A_?=a strategy-guide Gerrit =?UTF-8?B?V2Fyc+KEog==?=: a strategy-guide Gerrit Wars™: a strategy-guide I wouldn't be surprised if my message creates a fourth way. -- http://hexmode.com/ [We are] immortal ... because [we have] a soul, a spirit capable of compassion and sacrifice and endurance. -- William Faulker, Nobel Prize acceptance speech ___ 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] Encoding subject encoding bike shed
Heh, if clients randomly change character sets than I guess there are a very large number of possible values. Given that RFC2047 came out in 1996 it's reasonable that people use non-ascii characters in titles given that the means to do it in a compatible way has been around for 17 years. Luke On Thu, Mar 21, 2013 at 12:04 PM, Mark A. Hershberger m...@everybody.orgwrote: On 03/21/2013 11:45 AM, Luke Welling WMF wrote: On the email title sidetrack, it should not create a 4th way. The pedant in me says there are at least two more ways -- different capitalization for UTF-8. But your subject line shows another way. My client displays all of the subjects the same. Jasper, Mine: =?utf-8?q?Gerrit_Wars=E2=84=A2=3A_a_strategy-guide?= Yours: =?windows-1252?q?Gerrit_Wars=99=3A_a_strategy-guide?= MZ's: Gerrit =?UTF-8?B?V2Fyc+KEog==?=: a strategy-guide Ori: Gerrit =?utf-8?Q?Wars=E2=84=A2=3A_?=a strategy-guide Maybe mailman doesn't understand when the encoding doesn't start at the first character since those are the ones that don't display correctly. -- http://hexmode.com/ [We are] immortal ... because [we have] a soul, a spirit capable of compassion and sacrifice and endurance. -- William Faulker, Nobel Prize acceptance speech ___ 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] Default policy for third-party cookies in Firefox
If you want to play cat and mouse, a good reference for things that work is http://samy.pl/evercookie/ It's mostly targeted at a single domain stopping users from deleting cookies, but some of the same things should break cross domain security too. I'm not sure that end of web ethics is where we want to go in general but sleazy is a spectrum and depends on intent so there may be useful inspiration in it. Luke On Tue, Mar 19, 2013 at 12:56 PM, Greg Grossmeier g...@wikimedia.orgwrote: quote name=Seb35 date=2013-03-19 time=14:38:40 +0100 Hello, According to [1] and [2], Firefox 22 (release June 25, 2013) will change the default third-party cookie policy: a third-party cookie will be authorized only if there is already a cookie set on the third-party website. These two bugs are related to this: https://bugzilla.wikimedia.org/show_bug.cgi?id=45578 https://bugzilla.wikimedia.org/show_bug.cgi?id=45452 -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ 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] Pronunciation recording tool wanted
It would be a good application for mobile too. In browser would be reasonably easy with Flash, and can be done with JavaScript in modern browsers but not yet in a consistent way. There is a W3 spec but using a library like https://github.com/jussi-kalliokoski/sink.js/ would be easier than writing per browser versions to take into account current real world variation. A mobile app, or a few native apps for dominant platforms presumably expose a cleaner interface to what is a core device on that hardware, rather than an optional, variable peripheral on computers. Luke On Wed, Mar 13, 2013 at 4:03 AM, Matthew Flaschen mflasc...@wikimedia.orgwrote: On 03/13/2013 03:17 AM, Nikola Smolenski wrote: Why CC0 (public domain)? Your example (http://commons.wikimedia.org/wiki/File:Fr-go%C3%BBter.ogg) is CC-BY, which is not public domain and requires attribution (which I think all Wikimedia projects do for text). I'd say CC-BY-SA or CC-BY would be a better default. I am not sure about copyrightability of a pronunciation of a single word. Neither am I, but if it's licensed under one of those and a court finds it's not copyrightable, so be it. It still seems reasonable to use an attribution license. Matt Flaschen ___ 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] Query performance - run code faster, merge code faster :-)
The advice on https://wikitech.wikimedia.org/wiki/Query_profiling_for_features_developers sounds good. Is there more detail somewhere on how to do this part Test your query against production slaves prior to full deployment? Luke On Wed, Mar 6, 2013 at 8:14 PM, Matthew Flaschen mflasc...@wikimedia.orgwrote: On 03/06/2013 04:36 PM, Sumana Harihareswara wrote: If you want your code merged, you need to keep your database queries efficient. How can you tell if a query is inefficient? How do you write efficient queries, and avoid inefficient ones? We have some resources around: Roan Kattouw's https://www.mediawiki.org/wiki/Manual:Database_layout/MySQL_Optimization/Tutorial -- slides at https://commons.wikimedia.org/wiki/File:MediaWikiPerformanceProfiling.pdf Asher Feldman's https://www.mediawiki.org/wiki/File:MediaWiki_Performance_Profiling.ogv -- slides at https://www.mediawiki.org/wiki/File:SQL_indexing_Tutorial.pdf And https://wikitech.wikimedia.org/wiki/Query_profiling_for_features_developers Matt Flaschen ___ 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] Seemingly proprietary Javascript
I don't see the purpose of adding a licence string back on to JavaScript post-minification. Any recipient wanting to create a derivative work or redistribute those files is going to go back to the much more readable source files. It would be good form to add licence information to all the JS files in the same way we do for all the PHP files. Many or all of them are missing that now. Given they have a consistent licence, making that clear in each file is just grunt work. I don't see the need for that to survive minificaiton though. If somebody wants to auto verify licence status with software, they can run it on the original JS source before it get's minified. As others have implied regardless of whether you think satisfying the FSF is important, satisfying an automated tool is a concern that can be delegated to the tool owner. The licence status of on wiki user JavaScript is a separate issue, and possibly much more complicated. CC-BY-SA-3.0 is not an ideal licence for software, and it seems likely that there will be code pasted into some user JavaScript pages that is licensed under an incompatible licence. Luke Welling On Tue, Mar 5, 2013 at 10:57 AM, Mark Holmquist mtrac...@member.fsf.orgwrote: On Tue, Mar 05, 2013 at 12:56:23PM +0100, Alexander Berntsen wrote: GNU LibreJS blocks several Javascript sources around Wikipedia. I was sent to this list by Kirk Billund. My issue as well as Kirk's replies follows. I hope you are okay to read it in this form. https://bugzilla.wikimedia.org/show_bug.cgi?id=36866 We have this issue reported, it's on our radar, and I, at least, intend to fix it in the future. The user JavaScript and CSS might be an issue. I'm not sure how to handle that. I guess we could indicate in the license headers that some parts of the code are under the CC-BY-SA license, or whatever is set to the default license for the wiki. That should be possible, if not trivial. The minification process, however, does *not* cause a problem. We can simply add the comments to the file(s) after the minification. It does mean we'll need to include, potentially, multiple license headers in one HTTP response, but that shouldn't cause much issue. Alternatively we could use a mixed license header, and link to the texts of multiple licenses, or link to multiple files' source code. See the linked bug (above) for more discussion of the technical problems presented, and a few proposed suggestions. It looks like the best way to do it would be the bang comment syntax, suggested by Timo (Krinkle), which would allow each script to be tagged on its own, and that way each script authour would be responsible for their own licensing. I hope that helps, and that the bug discussion is a little more kind than wikitech has seemed :) -- Mark Holmquist Software Engineer Wikimedia Foundation mtrac...@member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist ___ 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] Seemingly proprietary Javascript
Yes. There seems little value in unqualified people debating if it is legally required. The mainstream FOSS licences all predate minification and seem to have been written with compiled languages in mind, not interpreted languages. Most have language that requires the licence in the source version, but not the binary version. Deciding whether minified JavaScript is technically or in spirit a binary form seems like something best left to experts. My conscience would certainly be clear if we only had a licence in our source distribution. Luke On Tue, Mar 5, 2013 at 12:25 PM, Marc A. Pelletier m...@uberbox.org wrote: On 03/05/2013 12:22 PM, Tyler Romeo wrote: it is nonetheless *legally required* to do so, regardless of the technical aspect of it I think that determination needs to be made by Counsel, not on a guess. I've quite some knowledge of copyright myself, and I know enough that the matter is subtle enough that this declaration is, at best, an oversimplification that cannot possibly reflect reality. -- Marc __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] Seemingly proprietary Javascript
We should discuss them separately, but this core mediawiki JS is GPL2 https://github.com/wikimedia/mediawiki-core/tree/master/resources This JS which was mentioned in the forwarded email that started this discussion is available via a wiki page so is probably under a CC-BY-SA-3.0 as it is submitted, edited and accessed like content. http://en.wikipedia.org/wiki/Wikipedia:WikiProject_User_scripts/Scripts#Scripts Luke On Tue, Mar 5, 2013 at 2:55 PM, Matthew Flaschen mflasc...@wikimedia.orgwrote: On 03/05/2013 09:47 AM, Isarra Yos wrote: The licensing information is on the page itself, of which the minified js winds up a part. For every file or other object that makes up the page to all contain the licensing information would be pretty unusual. It's like taking a file out of a page and then complaining that it has no licensing information when said information was in the page text right under it. What licensing information are you referring to? Of course, the code is not under the content license (content license being CC-BY-SA currently for Wikimedia). Matt Flaschen ___ 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] Better non-MySQL db support
Do we have an official position on cross database compatibility? Some of the MediaWiki SQL is in separate files and can be easily directed at a specific database engine. A lot of it though is scattered as fragments though other code and is going to be run on any engine we connect to. Specifically, do we use MySQL specific syntax that is more efficient (but breaks elsewhere) or do we attempt to write lowest common denominator SQL that will run more places, but not run as efficiently on our primary target? The only SQL coding standard doc I have seen treats Database and MySQL as synonyms: http://www.mediawiki.org/wiki/Manual:Coding_conventions/Database Luke Welling On Tue, Feb 26, 2013 at 5:37 AM, Dmitriy Sintsov ques...@rambler.ru wrote: 26 Февраль 2013 г. 14:27:06 пользователь Nikola Smolenski ( smole...@eunet.rs) написал: On 26/02/13 04:18, Matthew Flaschen wrote: Sure, for starters. :) Bear in mind, if we want to keep support for all these dbs, every change to the database schema has to (at some point) result in a change to separate SQL files for each DB (MySQL and SQLite use the same ones).For instance, there is a separate active oracle/tables.sql. I am wondering if it would make sense to give up on SQL, make universal table creation functions in PHP, the same way there are for other queries, and use that. Has anyone tried this before, is there other software that works like this? http://stackoverflow.com/**questions/108699/good-php-orm-**libraryhttp://stackoverflow.com/questions/108699/good-php-orm-library By the way, MySQL 5.6 is out and it supports fulltext search indexation for InnoDB tables. They also promise better peformance on large hardware. Still cannot find 12.04 ppa for 5.6.10, though and do not want to go troubles installing from source (although I installed MySQL from source some years ago).. Why going another database engines besides MySQL / MariaDB? Dmitriy __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] DevOps/Continuous Deployment discussion?
I am strongly of the opinion that within broad ranges deployment frequency does not matter. It really does not matter if you deploy twice an hour or every second day. But, having the machinery to make it so that you could deploy twice an hour if you wanted to is all kinds of valuable. Putting time into building: * Continuous integration with build-on-commit * Tests with good coverage * A staging environment that reflects production * Managed configuration * Scripted deployment to a large number of machines pays dividends in uptime, ops sanity and developer productivity even if you only use that machinery every few days. We have some of that, but heading further down that road would be a good thing even if we chose to keep organized periodic deployments. Luke Welling On Wed, Feb 20, 2013 at 2:04 PM, Juliusz Gonera jgon...@wikimedia.orgwrote: Sorry for digging up an old thread, but today I also started wondering if there's a way of making our deployments simpler and faster. I'm not a big fan of special highly orchestrated events when the whole team gathers and waits and then looks for regressions after deploying dozens of commits at the same time. I've been reading a bit and it's a fact that some projects do Continuous Deployment and it works for them: http://radar.oreilly.com/2009/**03/continuous-deployment-5-**eas.htmlhttp://radar.oreilly.com/2009/03/continuous-deployment-5-eas.html http://timothyfitz.com/2009/**02/10/continuous-deployment-** at-imvu-doing-the-impossible-**fifty-times-a-day/http://timothyfitz.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/ http://www.slideshare.net/**mikebrittain/mbrittain-**continuous-** deploymentalm3publichttp://www.slideshare.net/mikebrittain/mbrittain-continuous-deploymentalm3public Is there any interest at WMF in taking this path at some point? -- Juliusz On 12/26/2012 09:31 AM, Chris McMahon wrote: Hi, A number of people I know of have ideas and aspirations pertaining to a DevOps-style deployment process, a.k.a Continuous Deployment. In recent times a number of pieces of such a system have become functional: Zuul, Jenkins enhancements for tests, automated acceptance tests, etc. But looking at mediawiki.org I don't see any sort of central discussion of overall approach/design/process for DevOps/Continuous Deployment. Is it time to start such a discussion? Or is this premature? -Chris __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] MediaWiki API at Codecademy?
Do you want help? I don't know much about the API at the moment, but it is my Level-Up assignment this quarter. Documenting things is a good way to learn them. I have written a lot of courseware in the past. Luke Welling On Thu, Feb 7, 2013 at 6:20 PM, Yuri Astrakhan yuriastrak...@gmail.comwrote: I will be happy to part-take in this, as I do have some experience with the API :) I am heading the API v2 project, and this would be a natural extension of that. * RFC http://www.mediawiki.org/wiki/Requests_for_comment/API_Future * Action/Parameter Cleanup http://www.mediawiki.org/wiki/Requests_for_comment/API_Future/Naming_Cleanup On Thu, Feb 7, 2013 at 6:12 PM, Quim Gil q...@wikimedia.org wrote: Long story short: the MediaWiki API could be included at http://www.codecademy.com/**tracks/apis http://www.codecademy.com/tracks/apis if someone wants to do the work. Codecademy is happy to have us there. I think it is a good idea, in need of someone willing to drive this: - It is a good excuse to improve our API documentation at mediawiki.org. - Codecademy is a good place to reach to more developers. - Maybe it is a good chance for someone to take this as a paid job? The Wikimedia movement wants to spread the 1,3T of content we have, and get more free content from as many channels as possible. Our API plays a big role on this. Therefore, I *personally* believe that a project to update the API documentation at mediawiki.org and have corresponding exercises at Codecademy has a chance to receive a grant if the proposal and the candidate(s) are solid. Interested? Let me help you. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgil http://www.mediawiki.org/wiki/User:Qgil __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l 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 mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Why are we still using captchas on WMF sites?
I don't know if we are talking at cross purposes, or if I missed it, but this paper: http://elie.im/publication/text-based-captcha-strengths-and-weaknesses does not try to answer my question. What I want to know is *How many humans get turned away from editing Wikipedia by a difficult captcha?* The same authors have: http://elie.im/publication/how-good-are-humans-at-solving-captchas-a-large-scale-evaluation which is closer to what I want to know. They show humans solving different text based captures with an accuracy rate of 70% to 98%. Unfortunately, Wikipedia was not one of the captcha schemes they used in that study, and they don't attempt to measure how many people try again if they fail. If 2% of people fail on the first try but 90% of the fails reattempt and only 1% fail a second time that's an inconvenience, but probably worth it if it reduces the inconvenience of spam. If 30% of people fail on the first try and 90% of them give up and never try to edit again, that's a disaster. Luke On Wed, Jan 23, 2013 at 12:24 AM, Federico Leva (Nemo) nemow...@gmail.comwrote: Luke, we do not know how many humans are being turned away by the difficulty: actually we sort of do, that paper tells this as well. It's where their study came from, and gives recommendations on what captcha techniques are best for balancing efficacy with difficulty for humans. We don't seem to be following any (except waving, which, they say, shouldn't be used alone). Then, I'm not qualified to say if their recommendations are the best and I've not searched other studies, but it's not correct to say that we start from zero or that we have to study by ourselves (an unreasonable requirement that implies we'll never change anything until we'll be forced to make our wikis read-only due to spam, as many MediaWiki users before us). Nemo __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] Why are we still using captchas on WMF sites?
Even ignoring openness and privacy, exactly the same problems are present with reCAPTCHA as with Fancy Captcha. It's often very hard or impossible for humans to read, and is a big enough target to have been broken by various people. I don't know if it's constructive to brainstorm solutions to a problem before we measure the extent of the problem, but a viable compromise is very easy captchas. Spammers vary a great deal in sophistication but if we figure that any sophisticated enough to do any OCR are capable of finding and downloading existing public exploits of ours, then a block capital impact font captcha is equally easy for them, equally difficult for unsophisticated spammers and much easier for sighted humans. Luke On Tue, Jan 22, 2013 at 9:45 AM, Arthur Richards aricha...@wikimedia.orgwrote: On Tue, Jan 22, 2013 at 10:37 AM, vita...@yourcmc.ru wrote: Maybe you'll just use recaptcha instead of fancycaptcha? /me gets popcorn to watch recaptcha flame war There has been discussion on this list in the past about the use of recaptcha, but it has generally ended in a down-vote because reCaptcha is not open source (even though it supports free culture) nor is it something we can host on our own servers. -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ 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] Why are we still using captchas on WMF sites?
That was not the end of the problem I was referring to. We know our specific captcha is broken at turning away machines. As far as I am aware we do not know how many humans are being turned away by the difficulty of it. It's a safe bet that it is non-zero given the manual account requests we get, but given that we have people to do those kinds of experiments it would make sense to get a number from them before making any drastic decisions based on a reasonable gut feeling. I don't think anybody claims to have a perfect solution to the spam vs usability balancing act, so it's possible we'll try (and measure) a few approaches. Luke On Tue, Jan 22, 2013 at 10:16 AM, Federico Leva (Nemo) nemow...@gmail.comwrote: Luke, sorry for reiterating, but «brainstorm solutions to a problem before we measure the extent of the problem» is wrong: it's already been measured by others, see the other posts... Nemo __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] The ultimate bikeshed: typos in commit messages
I don't mind getting dinged for typos. If I'm being sloppy it's fair to point it out. However, I think the social contract should be that after I fix the typos you requested then you owe me a real code review where you look at the merits of the code. Code review is an awesomely useful but time consuming thing to provide. Patrolling for typos is not. Put it this way, if I concede and agree that the bikeshed can be green, the people who spent three hours arguing for green should feel obligated to turn up to the working bee to help with the painting. Luke Welling On Wed, Jan 16, 2013 at 10:40 AM, Bryan Tong Minh bryan.tongm...@gmail.comwrote: On Wed, Jan 16, 2013 at 7:26 PM, Jon Robson jdlrob...@gmail.com wrote: This is a ridiculous conversation and I can't believe it now spans +20 messages. Apparently you don't care, but other people do care. Please do not disregard other people's opinions because you believe yours is correct. To keep it in the style of this thread; attitudes like these do demotivate _me_. Also, I fully agree with Maarten's last comment. Bryan ___ 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] Problems uploading word 2007 .doc files
Is this bug the same issue? It looks like somebody put up a partial fix https://bugzilla.wikimedia.org/show_bug.cgi?id=38432 - Luke Welling On Mon, Jan 7, 2013 at 6:30 PM, Aran Dunkley a...@organicdesign.co.nzwrote: The file was a .doc, but I've tried changing it to docx and get the same result. Some other .doc and .docx files that are word 2007 upload no problem. But I don't see how it can complain when I have the MimeType verification disabled - completely disabling the verification would be no problem since only specific users can upload. p.s. this is a MW 1.19.2 on Ubuntu Server 11.10 with PHP 5.3.6 On 07/01/13 21:21, Matma Rex wrote: On Mon, 07 Jan 2013 23:47:58 +0100, Aran Dunkley a...@organicdesign.co.nz wrote: Hello, can someone please help me with this .doc upload problem? I've tried everything and even setting $wgVerifyMimeType to false fails to solve it. No matter what I do I keep getting the following error when I upload *some* word 2007 .doc files: The file is a corrupt or otherwise unreadable ZIP file. It cannot be properly checked for security. I don't know how that check can even be happening with $wgVerifyMimeType disabled, but still the error occurs?! Word 2007 uses a .docx format as far as I know, not .doc. Which one were you using in your configuration? Also, .docx files are essentially ZIP files with magic data inside. ___ 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 mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Jenkins: whitespace test!
It should be an ignorable warning. There are occasionally situations where trailing white space is necessary. MySQL for instance can be funny about combining multi line strings into one query, although I don't think it presents when called via PHP. Luke On Fri, Dec 21, 2012 at 9:59 AM, Chad innocentkil...@gmail.com wrote: On Fri, Dec 21, 2012 at 9:43 AM, Antoine Musso hashar+...@free.fr wrote: Hello, For a long time now we have been reviewing changes that contains unwanted trailing whitespaces. To make sure the patch submitter is warned about it, I have enabled trailing whitespace check on mediawiki/core.git The bug report is: https://bugzilla.wikimedia.org/42628 I have only enabled such check on the mediawiki/core.git repository for now. If that went well I will look up at enabling it on other repos. Is this a warning, or a failure? I really don't think we should *fail* patches for something that's almost always harmless. The only reason I ask is because you say warning here but failure on the bug. -Chad ___ 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] Jenkins: whitespace test!
And PS, as I've been dinged for this a few times this is now in my .vimrc to highlight trailing whitespace in vim. highlight ExtraWhitespace ctermbg=red guibg=red match ExtraWhitespace /\s\+$/ autocmd BufWInEnter * match ExtraWhitespace /\s\+$/ autocmd InsertEnter * match ExtraWhitespace /\s\+\%#\@!$/ autocmd InsertLeave * match ExtraWhitespace /\s\+$/ autocmd BufWInLeave * call clearmatches() On Fri, Dec 21, 2012 at 10:20 AM, Luke Welling WMF lwell...@wikimedia.orgwrote: It should be an ignorable warning. There are occasionally situations where trailing white space is necessary. MySQL for instance can be funny about combining multi line strings into one query, although I don't think it presents when called via PHP. Luke On Fri, Dec 21, 2012 at 9:59 AM, Chad innocentkil...@gmail.com wrote: On Fri, Dec 21, 2012 at 9:43 AM, Antoine Musso hashar+...@free.fr wrote: Hello, For a long time now we have been reviewing changes that contains unwanted trailing whitespaces. To make sure the patch submitter is warned about it, I have enabled trailing whitespace check on mediawiki/core.git The bug report is: https://bugzilla.wikimedia.org/42628 I have only enabled such check on the mediawiki/core.git repository for now. If that went well I will look up at enabling it on other repos. Is this a warning, or a failure? I really don't think we should *fail* patches for something that's almost always harmless. The only reason I ask is because you say warning here but failure on the bug. -Chad ___ 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] Any OSCON plans?
I've spoken at it the last 13 years, but I was thinking of skipping it this time. I've also been on the committee the last few years. I don't yet know if I will be this year, but if you want my perspective on what gets accepted I'd be happy to share it. In general state of TechnologyX is tough to get accepted unless you are Rasmus, Larry or Guido. How we did challenging new project at high profile site with technologyX is a much better bet. OSCON always runs some talks along the lines of saving the world with open culture, so a charismatic speaker with a non-obvious spin on that is worth a shot. Luke Welling On Fri, Dec 21, 2012 at 2:35 PM, Quim Gil q...@wikimedia.org wrote: OSCON call for papers is now open: July 22-26 at Portland (USA) http://www.oscon.com/oscon2013 Anybody considering? Thoughts? If we are interested: OSCON is a tough venue when it comes to get proposals accepted. Good planning and coordination does help, and this is why I'm asking here now. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] Video on mobile: Firefox works, way is paved for more browser support
FirefoxOS/Boot2Gecko phones presumably also support Ogg Theora and WebM formats, but they're not really a market share yet and may never be in the developed world. Without trying to downplay the importance of ideological purity, keep in mind that Mozilla, who have largely the same ideology on the matter have conceded defeat on the practical side of it after investing significant effort. Eg http://appleinsider. com/articles/12/03/14/mozilla_considers_h264_video_support_after_googles_vp8_fails_to_gain_traction With Google unwilling to commit the battle was winnable. There is not an ideologically pure answer that is compatible with the goal of taking video content and disseminating it effectively and globally. The conversation needs to be framed as what shade of grey is an acceptable compromise. Luke Welling On Wed, Dec 12, 2012 at 6:44 AM, Antoine Musso hashar+...@free.fr wrote: Le 12/12/12 00:15, Erik Moeller a écrit : Since there are multiple potential paths for changing the policy (keeping things ideologically pure, allowing conversion on ingestion, allowing h.264 but only for mobile, allowing h.264 for all devices, etc.), and since these issues are pretty contentious, it seems like a good candidate for an RFC which'll help determine if there's an obvious consensus path forward. Could we host h.264 videos and related transcoders in a country that does not recognize software patents? Hints: - I am not a lawyer - WMF has server in Netherlands, EU. -- Antoine hashar Musso ___ 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] Video on mobile: Firefox works, way is paved for more browser support
Thanks for the link. I'll try and stay out of it until I've had time to read the old thread, but I think this is an unfair characterization: On Wed, Dec 12, 2012 at 2:35 PM, David Gerard dger...@gmail.com wrote: This proposal is not about anything other than enhancing the shiny for owners of iOS devlces. It's about providing knowledge to the rapidly growing userbase of mobile device owners who fall outside the tiny segment that is Android users who have deliberately chosen to replace the stock Android browser with Firefox. Luke Welling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Escaping in SQL queries
I can't speak for all databases, but I know MySQL fairly well, and it will
generally be safe there.
You will be able to find some edge cases where it may not give you what you
expected. For example
select 0x10 + 1;
is not the same as
select '0x10' + 1;
The first will give 17, the second 1 as the string will get converted to 0,
but I don't know that there is a lot of non-decimal math being done here.
In most cases though, type conversion will work as you expect it too, the
following will all give 2
select '1' + '1'
select '1' + 1
select 1+ 1
Also, if we use MySQL's query cache, it is (or at least was) fairly naive
and compared query strings for an exact match so you will get a cache miss
if you run the same query twice but only include redundant quotes one time.
Quoting nulls would be a problem, but it is not doing that.
More importantly, the function strencode() called inside that addQuotes()
function is overridden for different underlying databases. The MySQL one
looks good. It is using mysql_real_escape_string and providing the
connection so the correct character set will be used.
It looks to me like the MS SQL version requires the programmer to manually
call encodeBlob() before building their query if they know they are
inserting binary data.
Luke Welling
On Tue, Dec 4, 2012 at 4:52 AM, Daniel Kinzler dan...@brightbyte.de wrote:
Hi all!
I recently found that it is less than clear how numbers should be
quoted/escaped
in SQL queries. Should DatabaseBase::addQuotes() be used, or rather just
inval(), to make sure it's really a number? What's the best practice?
Looking at DatabaseBase::makeList(), it seems that addQuotes() is used on
all
values, string or not. So, what does addQuotes() actually do? Does it
always add
quotes, turning the value into a string literal, or does it rather apply
whatever quoting/escaping is appropriate for the given data type?
addQuotes' documentation sais:
* If it's a string, adds quotes and backslashes
* Otherwise returns as-is
That's a plain LIE. Here's the code:
if ( $s === null ) {
return 'NULL';
} else {
# This will also quote numeric values. This should be harmless,
# and protects against weird problems that occur when they really
# _are_ strings such as article titles and string-number-string
# conversion is not 1:1.
return ' . $this-strencode( $s ) . ';
}
So, it actually always returns a quoted string literal, unless $s is null.
But is it true what the comment sais? Is it really always harmless to quote
numeric values? Will all database engines always magically convert them to
numbers before executing the query? If not, this may be causing table
scans.
That would be bad - but I suppose someone would have noticed by now...
So... at the very least, addQuotes' documentation needs fixing. And
perhaps it
would be nice to have an additional method that only applies the
appropriate
quoting, e.g. escapeValue or some such - that's how addQuotes seems to be
currently used, but that's not what it actually does... What do you think?
-- daniel
PS: There's more fun. The DatabaseMssql class overrides addQuotes to
support
Blob object. For the case $s is a Blob object, this code is used:
return ' . $s-fetch( $s ) . ';
The value is used raw, without any escaping. Looks like if there's a ' in
the
blob, fun things will happen. Or am I missing something?
___
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] Newbie licensing questions
These are prompted by Gerrit review comments, but it seems like a hidden place to discuss them. The specific background: A task I am on uses an external library licensed under the Apache2.0 license. Mediawiki core is shipped under a GPL2 license, so I'm guessing that is the default licence fondation work is released under. According to http://en.wikipedia.org/wiki/Apache_License#GPL_compatibilityApache licenses are compatible with GPL3 but not GPL2. The questions: Is my assumption that by default we put everything under GPL2 right? Are other FS/OSS licences OK to use? How paranoid are we? ie do we make a good faith effort at getting it right, or do we refer questions to internal counsel for a slower but safer answer? In this case my inclination is to licence the whole extension (containing the external library) as Apache2.0 but I'm happy to defer to normal process if there is one. Thanks, Luke Welling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF's webpage
Is there a reason not to use the Yahoo championed approach of embedding a version number in all static file names so you can set a very long cache expires time and just add new versions to the CDN when a change is made? I don't know how often our CSS, branding images, scripts, and other static content change, but there would not be much effort in adding that to a deploy process and there must be developer overhead being incurred in trying to keep new code backwards compatible. Luke Welling On Wed, Nov 28, 2012 at 5:52 PM, Platonides platoni...@gmail.com wrote: Code was updated to use h3 while the (cached) skin CSS still had h5 See http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2012-November/93.html Note: code was reverted to wmf4, so the problem will appear now in the reverse. We should use an intermediate CSS with rules appliying to portlets no matter if they are h3 or h5. Then migrate again in a few days. ___ 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] Proposed new WMF browser support framework for MediaWiki
Something that seems to be being partially considered in these models is browser shares that are growing or shrinking. For instance it would make more sense to me to support IE10 than IE7 even if IE7 has a far greater market share this month. If significant work is needed for IE7, it might have dropped below an age or market share threshold before that work is complete. By the same logic, it seems fair that mobile browsers make the list on a lower raw market share given that that market is likely to continue to grow for some time. Putting those rules (particularly for IE) into unambiguous, fair, numeric cutoffs may be hard. Predicting future IE market share depends a great deal on the vagaries of auto update policies and corporate IT departments. For instance Windows XP users are stuck on IE8 forever and there are probably quite a lot of them in corporate America. Luke Welling On Mon, Nov 26, 2012 at 2:53 PM, Tomasz Finc tf...@wikimedia.org wrote: Correction. I was looking at the total Other/Unknown. Opera is actually 4.66% --tomasz On Mon, Nov 26, 2012 at 11:00 AM, Tomasz Finc tf...@wikimedia.org wrote: On Fri, Nov 23, 2012 at 12:50 PM, James Forrester jforres...@wikimedia.org wrote: … which seems to be a little harsh on the mobile and tablet fronts, and overly- generous on the MSIE side given their exceptional costs to support per %age of users, but not too terrible. I worry less about it being harsh and more that it needs to be lined up with which documents the mobile teams current support matrix [1]. Removing Opera support as a general rule is not an option for us as it contributes a significant amount of readership traffic (6.69%) [2] . --tomasz [1] - http://www.mediawiki.org/wiki/Mobile/Testing_process [2] - http://stats.wikimedia.org/wikimedia/squids/SquidReportDevices.htm ___ 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] Wikimedia URL shortener
There are some practical reasons for providing site specific domain shortening beyond owning a cool domain hack. Discouraging the use of third party shorteners has real value. The web getting littered with urls that camouflage their destination, are tied to loss making commercial entities of unpredictable lifetime (eg tr.im), or tied to very well funded commercial entities that choose a ccTLD of unpredictable stability (eg bit.ly) is a bad thing. Providing the option of a short url that achieves whatever benefit was sought without breaking the way the web is supposed to work is a good thing. Email used to be problematic for url sharing, as line breaks inserted at 70 characters would mean the recipient needed to notice that some urls had been chopped and reassemble them. This is probably only true for mailing lists now, as people who deliberately use a plain text only email client in 2012 will experience obtrusive side effects from senders only providing an HTML MIME part regularly. URL chopping will not be their major annoyance. Mailing lists still routinely strip attachments and encodings from mail that they propagate. Mobile generally and twitter specifically are the most often cited justifications now. Aside from the obvious message length limits, cutting and pasting long strings can be hard on a small screen so people are in the short url habit. Twitter is an annoying use case, as even if presented with a short url it currently replaces it with a potentially longer t.co url. If all the project does is reduces the use of third party services that can permanently or transiently fail, can hide links to malware, break search engine rankings and search behaviour, and provide others with analytic insight into potentially sensitive user click throughs it is a good thing. Luke Welling PS my unobtainable cool domain hack of choice would be en.cy (but Cyprus don't do top level subdomains and require local presence) On Mon, Nov 19, 2012 at 5:49 AM, Neil Harris n...@tonal.clara.co.uk wrote: On 19/11/12 02:09, MZMcBride wrote: Tim Starling wrote: Providing a traditional URL shortener with traditional features would be useful, at least for some people, and would eliminate the need to use third-party URL shorteners internally, which have a commercial focus and unknown lifetime. If there was no integration with MW required, it would only take a couple of hours to set up. Who's using third-party URL shorteners internally? A lot of services would be useful to at least some people (Wikimedians), but the cost of setting up _and maintaining_ such a service can't be overlooked, in my opinion. Yes, it would take a few hours to set up a URL shortening service (if that), but who's going to be responsible for fixing bugs in it, adding features, and doing general maintenance to the service for the indefinite future? There are already a number of Wikimedia services that struggle for limited resources. Before we add another, we must answer the maintenance question. MZMcBride If a Wikimedia URL shortening service was to be created, it would make sense to, at the very least, (a) make the shortened link to real link mappings part of the standard Mediwiki XML dumps, so that they can be preserved alongside the content to which they refer, for access by future archivists, and (b) participate in initiatives such as the Internet Archive's 301works.org to preserve these links entirely outside the Wikimedia universe. Also, on a separate but related note, has anyone considered creating DOIs for individual wiki page revisions? -- Neil ___ 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
