Re: [Wikitech-l] Pronunciation recording tool wanted
On 13/03/13 02:01, Lars Aronsson wrote: Provide a tool on the toolserver, or any other server, having a simple link syntax that specifies the language code and the text, e.g. http://toolserver.org/mytool.php?lang=frtext=gouter I was thinking about this already and yes, this is a great idea! :) A very nice website that does this already is www.forvo.com but they claim by-nc-sa licence. But the way it works could be used as inspiration. A possible additional feature would be for speakers to indicate their locality, age, accent etc. (so that words differently pronounced in different accents of the same language would be marked as such). Another possible feature would be some sort of verification or someone might vandalize by cursing or similar (on Forvo this is done by voting). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pronunciation recording tool wanted
On 13/03/13 02:29, Brian Wolff wrote: It was solvable with a java applet (or flash, but that's usually considered evil) back in 2003. However it still requires someone to actually do it. I believe Flash should be Ok if made to work on gnash but am not sure if gnash supports everything needed. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pronunciation recording tool wanted
On 13/03/13 02:48, Matthew Flaschen wrote: The tool uses a cookie, that remembers that this user has agreed to submit contributions using cc0. At the first visit, this question is asked as a click-through license. 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. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pronunciation recording tool wanted
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] WebRequest and PHP bug 31892 fixed 6 years ago
Hello! WebRequest::getPathInfo() still depends on PHP bug 31892 fixed 6 years ago. I.e. WebRequest uses REQUEST_URI instead of mangled PATH_INFO which is not mangled since PHP 5.2.4. Yeah, Apache still replaces multiple /// with single /, but afaik it's done for REQUEST_URI as well as PATH_INFO. Maybe that part of the code should be removed? Also I don't understand the need for PathRouter - my IMHO is that it's just an unnecessary sophistication. As I understand EVERYTHING worked without it and there is no feature in MediaWiki which depends on a router. Am I correct? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WebRequest and PHP bug 31892 fixed 6 years ago
On Wed, Mar 13, 2013 at 8:22 PM, vita...@yourcmc.ru wrote: Also I don't understand the need for PathRouter - my IMHO is that it's just an unnecessary sophistication. As I understand EVERYTHING worked without it and there is no feature in MediaWiki which depends on a router. Am I correct? I doubt Daniel would have introduced it if it was un-necessary or pointless, I believe from memory it was to improve the handling of paths over a wide range of set-ups and environments (where sometimes it would fail). You would need to git blame the file and find the revision where it was introduced to confirm if that is truly the case (or if i'm mistaking it for other code) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] [Reminder] Fwd: [Language Engineering] Office hour on 13th March 2013, 1700UTC
Hello, This a reminder that the Language Engineering team will be having an office hour today i.e. 13th of March 2013, at 1700 UTC. The agenda can be found in the section below. Also, I'd like to apologize that the original mail was inadvertently not sent to the wikimedia-l list. Please do try to join in if you have the time. Thanks. Runa Agenda: # Introductions # MediaWiki Language Extension Bundle Release # Translate Extension (TUX) Updates # Updates about participation in various community events # Follow up from earlier office hours: Language Team (new) plans Testing Event plans # Q/A - We shall be taking questions during the session. Questions can also be sent to runa at wikimedia dot org before the event and can be addressed during the office-hour. -- Forwarded message -- From: Runa Bhattacharjee rbhattachar...@wikimedia.org Date: Tue, Mar 5, 2013 at 11:25 AM Subject: [Language Engineering] Office hour on 13th March 2013, 1700UTC To: wikitech-l@lists.wikimedia.org, mediawiki-i...@lists.wikimedia.org Hello, The Wikimedia Language Engineering team [1] invites everyone for the team’s monthly office hours on March 13, 2013. The team has lots of exciting updates about their projects, programs and events since the last office hour in November 2012. Some of this has already been shared in our recent blogs. Event details and the general agenda is mentioned below. See you all at the IRC office hour! Thanks Runa Event Details: Date: 2013-03-13 Time: 1700 UTC IRC channel: #wikimedia-office on irc.freenode.net Agenda: # Introductions # MLEB Release[2] # Translate UX[3] - Updates # Updates about participation in various community events # Follow up from earlier office hours: Language Team (new) plans Testing Event plans # Q/A - We shall be taking questions during the session. Questions can also be sent to runa at wikimedia dot org before the event and can be addressed during the office-hour. [1] http://wikimediafoundation.org/wiki/Language_Engineering_team [2] http://www.mediawiki.org/wiki/MediaWiki_Language_Extension_Bundle [3] http://www.mediawiki.org/wiki/Extension:Translate -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation ___ 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] Nightly shallow clones of mediawiki/core
On Tue, Mar 12, 2013 at 10:48 PM, Chad innocentkil...@gmail.com wrote: Version numbers in Git don't reflect any sort of reality in terms of features or things to look forward Sometimes I mention Semantic Versioning[1] to people that write code for a living and get surprised that they did not hear about it. Željko -- [1] http://semver.org/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Replacement for tagging in Gerrit
On Tue, 2013-03-12 at 20:28 -0700, Rob Lanphier wrote: If the problem is with the rigidity of keywords, one thing I should note is that, in addition to tagging, there's also the whiteboard in Bugzilla, which I believe you can use for free form stuff to query. I believe Andre only enabled that in recent months, so it may be that it wasn't available the last time you went looking, and is a feature we don't yet use for much (or anything?) IIRC the Whiteboard has always been available, just nobody used it. :) It's free-text format, so if you want to make sure to only find your own entries again I highly recommend using some namespace for your entries. I use the whiteboard to add aklapper-moreinfo entries whenever I would set a this report needs more info flag or status in other Bugzillas. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Virtual machines for testing IE
On Wed, Mar 13, 2013 at 1:31 AM, Matthew Flaschen mflasc...@wikimedia.orgwrote: Unlike before, they now even offer VirtualBox and VMWare images ievms[1] makes it even simpler to download all images. Željko -- [1] https://github.com/xdissent/ievms ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Nightly shallow clones of mediawiki/core
On Wed, Mar 13, 2013 at 11:02 AM, Željko Filipin zfili...@wikimedia.orgwrote: On Tue, Mar 12, 2013 at 10:48 PM, Chad innocentkil...@gmail.com wrote: Version numbers in Git don't reflect any sort of reality in terms of features or things to look forward Sometimes I mention Semantic Versioning[1] to people that write code for a living and get surprised that they did not hear about it. [1] http://semver.org/ Maybe that's because it's a buzzwordy new name for a very old idea? Although as described there, it tends to break if you have multiple different APIs that aren't necessarily in sync, or if the API is only a minor portion of the product. And marketing may complain if your competitor is at version 10 and you're at 2 (despite that being 2.98.917). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Meetup: Lua meets Wikipedia
Hi, there is a meetup tomorrow Thursday in San Francisco + video streaming: Lua meets Wikipedia http://www.meetup.com/Wikipedia-Engineering-Meetup/events/106078042/ The talks will start at about 6pm Pacific - 1:00 AM UTC http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130315T0100 Video will be streamed and stored at YouTube. The URLs will be available at the meetup page as soon as we have them. We are co-organizing this meetup with the Bay Area Lua Developers meetup, who has the first slot with a demo-based minimal crash course. SF(Rob Lanphier Aaron Schulz) + remote(Tim Starling Brad Jorsch) will continue with a session specific to Lua support in Wikipedia and MediaWiki in general. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A new feedback extension - review urgently needed
On Wed, 13 Mar 2013 00:37:52 +0100, Lukas Benedix bene...@zedat.fu-berlin.de wrote: Do you have any advice what I can do? Publicize. I had no idea anybody was doing anything like that, and I follow all channels worth following. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WebRequest and PHP bug 31892 fixed 6 years ago
I doubt Daniel would have introduced it if it was un-necessary or pointless, I believe from memory it was to improve the handling of paths over a wide range of set-ups and environments (where sometimes it would fail). You would need to git blame the file and find the revision where it was introduced to confirm if that is truly the case (or if i'm mistaking it for other code) I've looked at the annotations and what I've seen is that PathRouter only fixes https://bugzilla.wikimedia.org/show_bug.cgi?id=32621 by using path weights. Actually, I've started looking at the routing code after hitting this same bug with img_auth.php action path. But as I understand, it could be fixed much simpler just by reordering two parts of existing code and examining $wgArticlePath after $wgActionPaths :) And a single extension using the PathRouter is http://www.mediawiki.org/wiki/Extension:NamespacePaths ... Of course I support new features, there are some features that I myself would want to be in MW core :-) And I'm sure my point of view may be incorrect :-) but MW trunk (i.e. master) slightly frigtens me when compared to previous versions - the codebase seems to grow and grow and grow having more and more and more different helpers... And it becomes more and more complex with no simplification effort... (or maybe I'm just not aware of it) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Virtual machines for testing IE
On 03/13/2013 11:06 AM, Željko Filipin wrote: On Wed, Mar 13, 2013 at 1:31 AM, Matthew Flaschen mflasc...@wikimedia.orgwrote: Unlike before, they now even offer VirtualBox and VMWare images ievms[1] makes it even simpler to download all images. Cool, thank you. Matt ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] New unified SSL certificate (round two) to be deployed this afternoon
We will be pushing the new unified certificate this afternoon @ 2PM PDT. This new certificate will include all our primary top level domains, as well as the mobile subdomains. Unfortunately, those projects that have a sub.subdomain (example: arbcom.de.wikimedia.org) will have to redo their redirection rules and the like, as this will break them again. (As those users saw yesterday) The serial/fingerprint of the new certificate is: 07:24:ee:a9:7c:55:f2:57:5e:28:8b:a4:cc:f2:0e:8e A quick grep through the pdns files shows me the following projects will be affected by this change (and have to redo their redirections/whatnot): arbcom.de.wikipedia.org arbcom.en.wikipedia.org arbcom.fi.wikipedia.org arbcom.nl.wikipedia.org noboard.chapters.wikimedia.org This is all the ones that I found, but it may not be all inclusive. This change will fix certificate issues that have been around for awhile now, as listed in: https://bugzilla.wikimedia.org/show_bug.cgi?id=34788 If there are any questions or concerns, feel free to reply back to this thread. Thanks, -- Rob Halsell Operations Engineer Wikimedia Foundation, Inc. E-Mail: rhals...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WebRequest and PHP bug 31892 fixed 6 years ago
On Wed, 13 Mar 2013 11:40:08 -0700, vita...@yourcmc.ru wrote: I doubt Daniel would have introduced it if it was un-necessary or pointless, I believe from memory it was to improve the handling of paths over a wide range of set-ups and environments (where sometimes it would fail). You would need to git blame the file and find the revision where it was introduced to confirm if that is truly the case (or if i'm mistaking it for other code) I've looked at the annotations and what I've seen is that PathRouter only fixes https://bugzilla.wikimedia.org/show_bug.cgi?id=32621 by using path weights. Actually, I've started looking at the routing code after hitting this same bug with img_auth.php action path. But as I understand, it could be fixed much simpler just by reordering two parts of existing code and examining $wgArticlePath after $wgActionPaths :) And a single extension using the PathRouter is http://www.mediawiki.org/wiki/Extension:NamespacePaths ... Of course I support new features, there are some features that I myself would want to be in MW core :-) And I'm sure my point of view may be incorrect :-) but MW trunk (i.e. master) slightly frigtens me when compared to previous versions - the codebase seems to grow and grow and grow having more and more and more different helpers... And it becomes more and more complex with no simplification effort... (or maybe I'm just not aware of it) fixing bug 32621 is a todo. The first attempt failed and some tweaks are needed to use the PathRouter to fix that bug. PathRouter allows for the use of custom paths to expand. NamespacePaths is an example of one thing you can do (say giving Help: pages a /help/ path) but you could also apply that to special pages, etc... whatever. It's also the precursor to MW being able to handle 404s natively. The plan is in the future you'll just be able to throw everything that's not a file right at index.php and pretty urls, 404 pages, 404 thumbnail handlers, etc... will all just work natively without any special configuration. And by 404, I don't mean standard 404 pages like this: http://wiki.commonjs.org/404 I mean nice in-site 404 pages that actually help visitors find what they were looking for: http://www.dragonballencyclopedia.com/404 Not sure how PATH_INFO being unmangled fixes anything. There are other servers where PATH_INFO won't easily be outputted. REQUEST_URI handling works better in every case. And ?title=$1 in rewrite rules are evil. Determining what urls run what code has always been the job of the application in every good language, not the webserver. And we can do it using REQUEST_URI much more reliably than some webservers. Anyways, I wish I could just get rid of the PATH_INFO code. I have yet to hear of someone actually using it now that practically every webserver there is outputs REQUEST_URI meaning the PATH_INFO code is never reached. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New unified SSL certificate (round two) to be deployed this afternoon
This is finished. On Wed, Mar 13, 2013 at 11:43 AM, Rob Halsell rhals...@wikimedia.orgwrote: We will be pushing the new unified certificate this afternoon @ 2PM PDT. This new certificate will include all our primary top level domains, as well as the mobile subdomains. Unfortunately, those projects that have a sub.subdomain (example: arbcom.de.wikimedia.org) will have to redo their redirection rules and the like, as this will break them again. (As those users saw yesterday) The serial/fingerprint of the new certificate is: 07:24:ee:a9:7c:55:f2:57:5e:28:8b:a4:cc:f2:0e:8e A quick grep through the pdns files shows me the following projects will be affected by this change (and have to redo their redirections/whatnot): arbcom.de.wikipedia.org arbcom.en.wikipedia.org arbcom.fi.wikipedia.org arbcom.nl.wikipedia.org noboard.chapters.wikimedia.org This is all the ones that I found, but it may not be all inclusive. This change will fix certificate issues that have been around for awhile now, as listed in: https://bugzilla.wikimedia.org/show_bug.cgi?id=34788 If there are any questions or concerns, feel free to reply back to this thread. Thanks, -- Rob Halsell Operations Engineer Wikimedia Foundation, Inc. E-Mail: rhals...@wikimedia.org ___ 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] Replacement for tagging in Gerrit
Hi, On Tue, Mar 12, 2013 at 08:28:25PM -0700, Rob Lanphier wrote: The Bugzilla-based solution has some of the advantages of the MediaWiki-based solution. We may be able to implement it more quickly than something native to Gerrit because we're already working on Bugzilla integration, and we get features like queries for free, as well as the minor convenience of not having to have a new database table or two to manage. The problem at this point is that the gerrit-plugin interface is rather new, and that shows at various ends: * It's not possible to add GUI elements from a plugin. * Plugins cannot add their own database tables through gerrit. [...] So whatever we could possibly get into upstream gerrit, we should really try to get into upstream and not put into the plugin. But thinking about whether gerrit or bugzilla would be the correct place to store those tags ... It seems to me that the tags are not really tied to issues or changes, but rather to commits... Wouldn't git notes be a good match [1]? They're basically annotations attached to commits. You can add/remove them to any commit without changing the actual commit. And support comes directly with git, as for example in git log --show-notes Queries are just a grep away, and setting them can be done through git as well, until we integrate that into gerrit. Best regards, Christian P.S.: We already use git notes. They contain links to code review. But we could add lines like Tag: fixme and have them automatically show when reading the logs. -- quelltextlich e.U. \\ Christian Aistleitner Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65aEmail: christ...@quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax:+43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --- signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Replacement for tagging in Gerrit
Can git notes be changed after merge? Do they show in Gerrit diffs, so we don't accidentally lose them if someone else pushed an amend without the tags? Can they be removed after merge? Can one query for commits having a certain tag within a repo/branch/author? (eg. fixme commits by me in mw core) If not on displayed in Gerrit, then from git-cli via a web tool (how does that grep perform, is it fast enough?) Ofcourse, changing would still go from cli (not w/ the web tool). -- Krinkle On 14 mrt. 2013, at 00:07, Christian Aistleitner christ...@quelltextlich.at wrote: Hi, On Tue, Mar 12, 2013 at 08:28:25PM -0700, Rob Lanphier wrote: The Bugzilla-based solution has some of the advantages of the MediaWiki-based solution. We may be able to implement it more quickly than something native to Gerrit because we're already working on Bugzilla integration, and we get features like queries for free, as well as the minor convenience of not having to have a new database table or two to manage. The problem at this point is that the gerrit-plugin interface is rather new, and that shows at various ends: * It's not possible to add GUI elements from a plugin. * Plugins cannot add their own database tables through gerrit. [...] So whatever we could possibly get into upstream gerrit, we should really try to get into upstream and not put into the plugin. But thinking about whether gerrit or bugzilla would be the correct place to store those tags ... It seems to me that the tags are not really tied to issues or changes, but rather to commits... Wouldn't git notes be a good match [1]? They're basically annotations attached to commits. You can add/remove them to any commit without changing the actual commit. And support comes directly with git, as for example in git log --show-notes Queries are just a grep away, and setting them can be done through git as well, until we integrate that into gerrit. Best regards, Christian P.S.: We already use git notes. They contain links to code review. But we could add lines like Tag: fixme and have them automatically show when reading the logs. -- quelltextlich e.U. \\ Christian Aistleitner Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65aEmail: christ...@quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax:+43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --- ___ 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] Replacement for tagging in Gerrit
On Thu, Mar 14, 2013 at 12:07 AM, Christian Aistleitner christ...@quelltextlich.at wrote: Hi, On Tue, Mar 12, 2013 at 08:28:25PM -0700, Rob Lanphier wrote: The Bugzilla-based solution has some of the advantages of the MediaWiki-based solution. We may be able to implement it more quickly than something native to Gerrit because we're already working on Bugzilla integration, and we get features like queries for free, as well as the minor convenience of not having to have a new database table or two to manage. The problem at this point is that the gerrit-plugin interface is rather new, and that shows at various ends: * It's not possible to add GUI elements from a plugin. * Plugins cannot add their own database tables through gerrit. [...] So whatever we could possibly get into upstream gerrit, we should really try to get into upstream and not put into the plugin. But thinking about whether gerrit or bugzilla would be the correct place to store those tags ... It seems to me that the tags are not really tied to issues or changes, but rather to commits... Wouldn't git notes be a good match [1]? +1 rupert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A new feedback extension - review urgently needed
On 2013-03-12 8:38 PM, Lukas Benedix bene...@zedat.fu-berlin.de wrote: Do you have any advice what I can do? Don't take this the wrong way, but you should perhaps start considering a plan b. Community contributed extensions often take months before getting deployed. While that's not always the case, it is the likely case. You should also probably work on getting approval from the wikidata community. Its unlikely the extension will be deployed unless there is agreement at wikidata that the extension is wanted. (From what I've seen you left a comment on the vp to which no one responded to. That is not usually sufficient. Usually you have to get a bunch of people to actively support you) Best of luck, --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A new feedback extension - review urgently needed
On 03/13/2013 08:00 PM, Brian Wolff wrote: On 2013-03-12 8:38 PM, Lukas Benedix bene...@zedat.fu-berlin.de wrote: Do you have any advice what I can do? Don't take this the wrong way, but you should perhaps start considering a plan b. Community contributed extensions often take months before getting deployed. While that's not always the case, it is the likely case. You should also probably work on getting approval from the wikidata community. Its unlikely the extension will be deployed unless there is agreement at wikidata that the extension is wanted. (From what I've seen you left a comment on the vp to which no one responded to. That is not usually sufficient. Usually you have to get a bunch of people to actively support you) Best of luck, --bawolff Lukas, I have to regretfully agree with Brian. Please do consider alternative means to test the feedback mechanisms in your project; it is unlikely that, within the next 2-3 weeks, you will be able to get through the multiple rounds of revision needed to meet design and technical deployment standards. If you set up a test wiki with this functionality then we can ask people to try it out, to ensure you get data from a few dozen people. You won't be the first researcher who had to change the proposed experimental method for pragmatic reasons. :/ -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New unified SSL certificate deployed
- Original Message - From: Ryan Lane rlan...@gmail.com We just finished deploying a new SSL certificate to the sites. Now all *.m and *. certificates are included in a single certificate, except mediawiki.org. Unfortunately we somehow forgot mediawiki.org when we ordered the updated cert. We'll be replacing this soon with another cert that had mediawiki.org included. This should fix any certificate errors that folks have been seeing on non-wikipedia m. domains. Hey, Ryan; did you see, perhaps on outages-discussion, the after action report from Microsoft about how their Azure SSL cert expiration screwup happened? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New unified SSL certificate deployed
On Wed, Mar 13, 2013 at 8:12 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Ryan Lane rlan...@gmail.com We just finished deploying a new SSL certificate to the sites. Now all *.m and *. certificates are included in a single certificate, except mediawiki.org. Unfortunately we somehow forgot mediawiki.org when we ordered the updated cert. We'll be replacing this soon with another cert that had mediawiki.org included. This should fix any certificate errors that folks have been seeing on non-wikipedia m. domains. Hey, Ryan; did you see, perhaps on outages-discussion, the after action report from Microsoft about how their Azure SSL cert expiration screwup happened? What's the relevance here? - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New unified SSL certificate deployed
On Mar 13, 2013 11:13 PM, Jay Ashworth j...@baylink.com wrote: Hey, Ryan; did you see, perhaps on outages-discussion, the after action report from Microsoft about how their Azure SSL cert expiration screwup happened? Can you just link to the discussion archive? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New unified SSL certificate deployed
- Original Message - From: Ryan Lane rlan...@gmail.com Hey, Ryan; did you see, perhaps on outages-discussion, the after action report from Microsoft about how their Azure SSL cert expiration screwup happened? What's the relevance here? Does ops have a procedure for avoiding unexpected SSL cert expirations, and does this affect it in any way other than making it easier to implement?, I would think... Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New unified SSL certificate deployed
- Original Message - From: Jeremy Baron jer...@tuxmachine.com Can you just link to the discussion archive? Was a posting: http://blogs.msdn.com/b/windowsazure/archive/2013/03/01/details-of-the-february-22nd-2013-windows-azure-storage-disruption.aspx Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Virtual machines for testing IE
13 Март 2013 г. 22:42:57 пользователь Matthew Flaschen (mflasc...@wikimedia.org) написал: On 03/13/2013 11:06 AM, Željko Filipin wrote: On Wed, Mar 13, 2013 at 1:31 AM, Matthew Flaschen mflasc...@wikimedia.orgwrote: Unlike before, they now even offer VirtualBox and VMWare images ievms[1] makes it even simpler to download all images. Cool, thank you. Matt Aren't these Windows systems bundled into VM images get expired every month or so so you have to re-download huge images again and again? I used to download and run IE tests for custom MW scripts / skins about 1.5 years ago, it was really tiresome and slow. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Virtual machines for testing IE
On 03/14/2013 01:11 AM, Dmitriy Sintsov wrote: Aren't these Windows systems bundled into VM images get expired every month or so so you have to re-download huge images again and again? I used to download and run IE tests for custom MW scripts / skins about 1.5 years ago, it was really tiresome and slow. They used to be (not sure if it was a month). I don't know what the current time period is. It seems like modern.ie is trying to make the process easier (e.g. native VirtualBox support), so I wouldn't be surprised if they've made the activation a little easier. There are other options though, like Sauce Labs, Browserstack, etc. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: New unified SSL certificate deployed
On Wed, Mar 13, 2013 at 9:24 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Ryan Lane rlan...@gmail.com Hey, Ryan; did you see, perhaps on outages-discussion, the after action report from Microsoft about how their Azure SSL cert expiration screwup happened? What's the relevance here? Does ops have a procedure for avoiding unexpected SSL cert expirations, and does this affect it in any way other than making it easier to implement?, I would think... We didn't have a certificate expiration. We replaced all individual certificates, delivered by different top level domains, with a single unified certificate. This change was to fix certificate errors being shown on all non-wikipedia domains for HTTPS mobile users, who were being delivered the *.wikipedia.org certificate for all domains. The unified certificate was missing 6 Subject Alternative Names: mediawiki.org, *.mediawiki.org, m.mediawiki.org, *.m.mediawiki.org, m.wikipedia.org and *.m.wikipedia.org. Shortly after deploying the certificate we noticed it was bad and reverted the affected services ( mediawiki.org and mobile) back to their individual certificates. The change only affected a small portion of users for a short period of time. If you notice, I've already mentioned how we'll avoid and more quickly detect problems like this in the future: Needless to say I'll be writing a script that can be run against a cert to ensure it's not missing anything. We'll also be adding monitoring to check for invalid certificates for any top level domain. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
