Re: [Wikitech-l] gerrit support question: how to show raw file content after the commit in the browser, not as zip download
I found a solution to the problem: If a gerrit administrator declares the mimetypes of the files to be safe they will be displayed in-browser rather than downloaded as zip files: https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#_a_id_mimetype_a_section_mimetype Could someone edit the gerrit.config file to declare php, javascript, and css files as 'safe'? Ryan Kaldari On 12/11/12 10:47 AM, Ryan Kaldari wrote: This is actually my biggest annoyance with gerrit—that I can't view raw code from the change view. I can't fathom why they have a zip download link, but not a view link. Then I could copy code without copying all the line numbers. Ryan Kaldari On 12/11/12 9:25 AM, Niklas Laxström wrote: On 11 December 2012 11:42, Thomas Gries m...@tgries.de wrote: While tracking an iusse I came to https://gerrit.wikimedia.org/r/#/c/7986/ (example case) In the list of files I clicked on https://gerrit.wikimedia.org/r/#/c/7986/14/includes/UserMailer.php Now I am desperately seeking a link to _show the raw file content after the commit in the __browser__,__ _but only found a link (Download) which starts a zip download. This is not what I wanted. Is there a solution which I have overlooked? If you just want to view the content, in diff view click Preferences, on the left bottom choose Whole File as context and click Update. It is no good for copy-pasting though. -Niklas -- Niklas Laxström ___ 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] Alpha version of the VisualEditor now available on the English Wikipedia
tl;dr: VE does not work for me https://bugzilla.wikimedia.org/show_bug.cgi?id=42988 Hanging after Review and save -- Review your changes hangs, no saving ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mobile apps: time to go native?
Στις 11-12-2012, ημέρα Τρι, και ώρα 19:04 -0500, ο/η MZMcBride έγραψε: Brion Vibber wrote: Over on the mobile team we've been chatting for a while about the various trade-offs in native vs HTML-based (PhoneGap/Cordova) development. [...] iOS and Android remain our top-tier mobile platforms, and we know we can do better on them than we do so far... Any thoughts? Wildly in favor or against? snip Looking at the big picture, I don't think we'll ever see widespread editing from mobile devices. The user experience is simply too awful. The best I think most people are hoping for is the ability to easily fix a typo, maybe, but even then you have to assess costs vs. benefit. That is, is it really worth paying two or three full-time employees so that someone can easily change Barrack to Barack from his or her iPhone? Probably not. Actually I think this one of the very things we really want to target. How many readers become editors after sitting down and writing a full article with references from scratch? How many make a small change, fix a typo or a date or a grammatical error, tweak a sentence or two? Making this work well on mobile devices seems to me like time and resources well spent; I'm less convinced that folks need to be able to add complex infoboxes but that discussion can be put off until more modest goals are achieved. By then the landscape will have shifted again and we can re-evaluate. I don't know if that is best achieved via a native platform or not. There were a couple of previous projects that were all about making small edits (e.g. [1]). How well can such an approach be adapted for mobile use? Ariel [1] http://www.mediawiki.org/wiki/Extension:InlineEditor ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Jenkins and extension parser tests
Hi Platonides, Thanks for your response (and I extend my thanks to NikeRabbit, who improved the extension unit test page a lot!). On 12 December 2012 00:04, Platonides platoni...@gmail.com wrote: If you only want to run parser tests from a different file, there's no need to create a new class. You simply add in the main file: $wgParserTestFiles[] = dirname( __FILE__ ) . /lstParserTests.txt; It will be automagically picked when running the phpunit tests Yes, they are, as long as you are running the entire test suite. However, it doesn't allow you to just run a specific extensions' parser tests by calling phpunit.php on that extension's directory, which is (as far as I could find out) what Jenkins does. make parser comes close, but it also runs all other parser tests - so it runs 5000 tests instead of the 35-ish relevant ones. You can also run them with tests/parserTests.php This is indeed an effective way (and what I've been doing manually), (it's also the way that has been documented at http://www.mediawiki.org/wiki/Parser_tests ). Again, thanks for your response. Merlijn ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikimedia Open Tech Chat tomorrow
Hi there! Tomorrow at 20:30 UTC (12:30 PST, 21:30 CET, 02:00 IST) there will be another Wikimedia Open Tech Chat[1] on Google Hangout. This time there are three topics. I'd love to see you there. Please come! Topics: * An update by the Quality Assurance department on browser test automation * Internationalisation dos and don'ts: Why you should not merge your patch set, but request i18n/L10n review (Amir Aharoni) * Multilingual user testing for improving the Translate extension (Pau Giner) The Hangout URL will be published about 5 minutes in advance and QA can go through the #wikimedia-dev IRC channel on Freenode. If you're in San Francisco, consider joining in the flesh on the 6th floor of the Wikimedia Foundation SF office's Collab space. The session will last between 60 and 90 minutes. The session will be moderated by Rob Lanphier. [1] https://www.mediawiki.org/wiki/Meetings/2012-12-13 Cheers! P.s. Would you have read this mail sooner if its subject would have been Pictures of cute cats? Initially I was planning to give it this subject, but I changed my mind... Whatever the answer: Thanks for reading and do come! -- Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On Tuesday, December 11, 2012 at 7:30 PM, James Forrester wrote: TL;DR: Today we are launching an alpha, opt-in version of the VisualEditor[0] to the English Wikipedia. This will let editors create and modify real articles visually, using a new system where the articles they edit will look the same as when you read them, and their changes show up as they type enter them — like writing a document in a word processor. Please let us know what you think[1]. This is very exciting. Congratulations, VE team! -- Ori Livneh ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] gerrit support question: how to show raw file content after the commit in the browser, not as zip download
On 12/12/12 09:09, Ryan Kaldari wrote: I found a solution to the problem: If a gerrit administrator declares the mimetypes of the files to be safe they will be displayed in-browser rather than downloaded as zip files: https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#_a_id_mimetype_a_section_mimetype Could someone edit the gerrit.config file to declare php, javascript, and css files as 'safe'? Ryan Kaldari I don't think we should set javascript mimetype as safe. Not when using its own one at least. ___ 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
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
Re: [Wikitech-l] gerrit support question: how to show raw file content after the commit in the browser, not as zip download
On Wed, Dec 12, 2012 at 3:09 AM, Ryan Kaldari rkald...@wikimedia.org wrote: I found a solution to the problem: If a gerrit administrator declares the mimetypes of the files to be safe they will be displayed in-browser rather than downloaded as zip files: https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#_a_id_mimetype_a_section_mimetype Could someone edit the gerrit.config file to declare php, javascript, and css files as 'safe'? That doesn't quite work the way you're thinking--it's for us to define mimetypes that Gerrit should show diffs of (rather than a zip download of the file). All text- based filetypes are already shown by the browser as diffs, but most binary filetypes aren't shown on diff. Images originally suffered this problem, but we fixed it[0]. There's not a config switch for what the OP is asking for--but feel free to file a bug upstream[1] :) -Chad [0] https://bugzilla.wikimedia.org/show_bug.cgi?id=36852 [1] https://code.google.com/p/gerrit/issues/list ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] gerrit support question: how to show raw file content after the commit in the browser, not as zip download
Le 11/12/12 19:47, Ryan Kaldari wrote: Then I could copy code without copying all the line numbers. We could apply 'user-select: none;' to the element containing the line number. It is not supported on all browsers though. I think I used that in our old Special:CodeReview. I could not find the patch though. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Ops] mariadb 5.5 in production for english wikipedia
Awesome!
On Tue, Dec 11, 2012 at 8:49 PM, Terry Chay tc...@wikimedia.org wrote:
If it works out, then at some point we should probably tell the MariaDB peeos
that they can mention that the WMF uses it. :-)
The enwiki article on MariaDB has claimed MediaWiki officially
supports it since October 2012.[1] Perhaps that's a {{citation
needed}}.
[1]: https://en.wikipedia.org/w/index.php?diff=prevoldid=519286745
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mobile apps: time to go native?
On Tue, Dec 11, 2012 at 8:11 PM, MZMcBride z...@mzmcbride.com wrote: I think I fundamentally agree with your point, but when I consider that there is (for example) no API for adding or removing a category from a page (file or otherwise), Sure there is, action=edit. Although the client does need to do some minimal manipulation of the wikitext. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Ops] mariadb 5.5 in production for english wikipedia
On 12 December 2012 14:28, Brad Jorsch bjor...@wikimedia.org wrote:
The enwiki article on MariaDB has claimed MediaWiki officially
supports it since October 2012.[1] Perhaps that's a {{citation
needed}}.
[1]: https://en.wikipedia.org/w/index.php?diff=prevoldid=519286745
I would have thought it would have Just Worked in MediaWiki (the
software) for a long time.
- d.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Ops] mariadb 5.5 in production for english wikipedia
On Wed, Dec 12, 2012 at 9:34 AM, David Gerard dger...@gmail.com wrote:
On 12 December 2012 14:28, Brad Jorsch bjor...@wikimedia.org wrote:
The enwiki article on MariaDB has claimed MediaWiki officially
supports it since October 2012.[1] Perhaps that's a {{citation
needed}}.
[1]: https://en.wikipedia.org/w/index.php?diff=prevoldid=519286745
I would have thought it would have Just Worked in MediaWiki (the
software) for a long time.
It probably did. But [[mw:Manual:Installation guide]] still says it's
not officially supported.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia Open Tech Chat tomorrow
On Wed, Dec 12, 2012 at 4:43 AM, Siebrand Mazeland (WMF) smazel...@wikimedia.org wrote: P.s. Would you have read this mail sooner if its subject would have been Pictures of cute cats? Initially I was planning to give it this subject, but I changed my mind... I would probably have deleted it unread in that case. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] mariadb 5.5 in production for english wikipedia
Le 12/12/12 01:10, Asher Feldman a écrit : This afternoon, I migrated one of the main production English Wikipedia slaves, db59, to MariaDB 5.5.28. Congratulations :-) Out of curiosity, have you looked at Drizzle too? -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Ops] mariadb 5.5 in production for english wikipedia
On 12 December 2012 14:38, Brad Jorsch bjor...@wikimedia.org wrote:
On Wed, Dec 12, 2012 at 9:34 AM, David Gerard dger...@gmail.com wrote:
On 12 December 2012 14:28, Brad Jorsch bjor...@wikimedia.org wrote:
The enwiki article on MariaDB has claimed MediaWiki officially
supports it since October 2012.[1] Perhaps that's a {{citation
needed}}.
[1]: https://en.wikipedia.org/w/index.php?diff=prevoldid=519286745
I would have thought it would have Just Worked in MediaWiki (the
software) for a long time.
It probably did. But [[mw:Manual:Installation guide]] still says it's
not officially supported.
I expect when it's on more of the cluster someone can announce its
enhanced status here :-)
- d.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Ops] mariadb 5.5 in production for english wikipedia
This is awesome! Is there any write-up of the migration process floating
around?
-Tom
On Wed, Dec 12, 2012 at 10:06 AM, David Gerard dger...@gmail.com wrote:
On 12 December 2012 14:38, Brad Jorsch bjor...@wikimedia.org wrote:
On Wed, Dec 12, 2012 at 9:34 AM, David Gerard dger...@gmail.com wrote:
On 12 December 2012 14:28, Brad Jorsch bjor...@wikimedia.org wrote:
The enwiki article on MariaDB has claimed MediaWiki officially
supports it since October 2012.[1] Perhaps that's a {{citation
needed}}.
[1]: https://en.wikipedia.org/w/index.php?diff=prevoldid=519286745
I would have thought it would have Just Worked in MediaWiki (the
software) for a long time.
It probably did. But [[mw:Manual:Installation guide]] still says it's
not officially supported.
I expect when it's on more of the cluster someone can announce its
enhanced status here :-)
- d.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Ops] mariadb 5.5 in production for english wikipedia
On 12 December 2012 15:32, Thomas Fellows thomas.fell...@gmail.com wrote: This is awesome! Is there any write-up of the migration process floating around? +1 In fact, this would be a nice thing to put on the WMF blog. It'll certainly get a lot of linkage and reporting around the geekosphere. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Groups are official: start your own!
On Wed, Dec 12, 2012 at 4:06 AM, David Gerard dger...@gmail.com wrote: There used to be Wiki Wednesdays in London - not just MediaWiki or Wikipedia - but all sorts of wikis. Mostly corporate users. These petered out from lack of general interest, though. It surprises me, as I'd expect a lot of people using MW in London. Thank you for mentioning Wiki Wednesday. Wiki Wednesday is a long-standing institution that seems to have lost popularity over the past several years. Socialtext used to promote Wiki Wednesday pretty heavily in the Bay Area and elsewhere: https://www.socialtext.net/wikiwed/ . Socialtext today is radically different than it was then, and Wiki Wednesday became much less a priority for them. Wiki Wednesday was the first of many such ideas: http://ashub.blogspot.com/2005/06/tag-tuesday.html Ward Cunningham is still doing Wiki Wednesday activities today: http://twitter.com/WardCunningham/status/238315318345347074 On one hand, I think aligning Mediawiki Groups with the venerable tradition of Wiki Wednesday might be worthwhile. Wiki Wednesday is a concept that already exists, and I think people like Ward would be happy to see it promoted more than it has been. On the other hand, interest in Wiki Wednesday has died down in recent years, and that might reflect badly on a new but similar project. -Chris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
Would it be possible to enable VE on test2 in the same way? I would like to use it in a noisy way, and would rather not make noise on enwiki. -Chris On Tue, Dec 11, 2012 at 8:30 PM, James Forrester jforres...@wikimedia.orgwrote: TL;DR: Today we are launching an alpha, opt-in version of the VisualEditor[0] to the English Wikipedia. This will let editors create and modify real articles visually, using a new system where the articles they edit will look the same as when you read them, and their changes show up as they type enter them — like writing a document in a word processor. Please let us know what you think[1]. Why launch now? We want our community of existing editors to get an idea of what the VisualEditor will look like in the “real world” and start to give us feedback about how well it integrates with how they edit right now, and their thoughts on what aspects are the priorities in the coming months. The editor is at an early stage and is still missing significant functions, which we will address in the coming months. Because of this, we are mostly looking for feedback from experienced editors at this point, because the editor is insufficient to really give them a proper experience of editing. We don’t want to promise an easier editing experience to new editors before it is ready. As we develop improvements, they will be pushed every fortnight to the wikis, allowing you to give us feedback[1] as we go and tell us what next you want us to work on. How can I try it out? The VisualEditor is now available to all logged-in accounts on the English Wikipedia as a new preference, switched off by default. If you go to your “Preferences” screen and click into the “Editing” section, it will have as an option labelled “Enable VisualEditor”). Once enabled, for each article you can edit, you will get a second editor tab labelled “VisualEditor” next to the “Edit” tab. If you click this, after a little pause you will enter the VisualEditor. From here, you can play around, edit and save real articles and get an idea of what it will be like when complete. At this early stage in our development, we recommend that after saving any edits, you check whether they broke anything. All edits made with the VisualEditor will show up in articles’ history tabs with a “VisualEditor” tag next to them, so you can track what is happening. Things to note Slow to load - It will take some time for long complex pages to load into the VisualEditor, and particularly-big ones may timeout after 60 seconds. This is because pages have to be loaded through Parsoid which is also in its early stages, and is not yet optimised for deployment and is currently uncached. In the future (a) Parsoid itself will be much faster, (b) Parsoid will not depend on as many slow API calls, and (c) it will be cached. Odd-looking - we currently struggle with making the HTML we produce look like you are used to seeing, so styling and so on may look a little (or even very) odd. This hasn't been our priority to date, as our focus has been on making sure we don't disrupt articles with the VisualEditor by altering the wikitext (correct round-tripping). No editing references or templates - Blocks of content that we cannot yet handle are uneditable; this is mostly references and templates like infoboxes. Instead, when you mouse over them, they will be hatched out and a tooltip will inform you that they have to be edited via wikitext for now. You can select these items and delete them entirely, however there is not yet a way to add ones in or edit them currently (this will be a core piece of work post-December). Incomplete editing - Some elements of complex formatting will display and let you edit their contents, but not let users edit their structure or add new entries - such as tables or definition lists. This area of work will also be one of our priorities post-December. No categories - Articles' meta items will not appear at all - categories, langlinks, magic words etc.; these are preserved (so editing won't disrupt them), but they not yet editable. Another area for work post-December - our current plan is that they will be edited through a metadata flyout, with auto-suggestions and so on. Poor browser support - Right now, we have only got VisualEditor to work in the most modern versions of Firefox, Chrome and Safari. We will find a way to support (at least) Internet Explorer post-December, but it's going to be a significant piece of work and we have failed to get it ready for now. Articles and User pages only - The VisualEditor will only be enabled for the article and user namespaces (so you can make changes in a personal sandbox), and will not work with talk pages, templates, categories, etc.. In time, we will build out the kinds of specialised editing tools needed for non-articles, but our focus has been on articles. Final point This is not the final form of the
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On Wed, Dec 12, 2012 at 10:58 AM, Chris McMahon cmcma...@wikimedia.org wrote: Would it be possible to enable VE on test2 in the same way? I would like to use it in a noisy way, and would rather not make noise on enwiki. It's also enabled for the user namespace, so people can feel free to play with it and not be afraid of messing up a real article. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On Wed, Dec 12, 2012 at 8:59 AM, Chad innocentkil...@gmail.com wrote: On Wed, Dec 12, 2012 at 10:58 AM, Chris McMahon cmcma...@wikimedia.org wrote: Would it be possible to enable VE on test2 in the same way? I would like to use it in a noisy way, and would rather not make noise on enwiki. It's also enabled for the user namespace, so people can feel free to play with it and not be afraid of messing up a real article. I was thinking of making some basic automated browser tests for it. test2 is more handy than enwiki for that. Beta labs would be even better. -Chris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On Wed, Dec 12, 2012 at 8:59 AM, Chad innocentkil...@gmail.com wrote: On Wed, Dec 12, 2012 at 10:58 AM, Chris McMahon cmcma...@wikimedia.org wrote: Would it be possible to enable VE on test2 in the same way? I would like to use it in a noisy way, and would rather not make noise on enwiki. It's also enabled for the user namespace, so people can feel free to play with it and not be afraid of messing up a real article. I was thinking of making some basic automated browser tests for it. test2 is more handy than enwiki for that. Beta labs would be even better. -Chris This will also be useful to the Parsoid team as well so we can test changes to parsoid itself more thoroughly (outside the rt-testing and parser tests that we already use). This would require the VE instance to use a different Parsoid instance which could be the existing one at parsoid.wmflabs.org, for example. Subbu. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On Tue, 2012-12-11 at 19:30 -0800, James Forrester wrote: This is not the final form of the VisualEditor in lots of different ways. We know of a number of bugs, and we expect you to find more. We do not recommend people trying to use the VisualEditor for their regular editing yet. We would love your feedback on what we have done so far – whether it’s a problem you discovered, an aspect that you find confusing, what area you think we should work on next, or anything else, please do let us know.[1] [1] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback Playing the bad cop who's reading random feedback pages daily: As https://www.mediawiki.org/wiki/VisualEditor/Feedback also exists I wonder if the VisualEditor deployment on en.wp and its related feedback is so different from upstream that it needs a separate feedback page (instead of e.g. a soft redirect to the mw: one), or other reasons. Or does the en.wp one somehow make it easier for testers to report issues? When we deploy VE to other Wikipedias, will there also be separate VE feedback pages (maybe due to the different languages)? Note: I'm not criticizing it, I'm just trying to understand, and I'm picking VE as the most recent example. Thanks in advance for explaining, 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] Mobile apps: time to go native?
Have a link? 'Cheap smartphone' seems a contradiction. $50 Huawei phones running an ancient Android and only getting cheaper. Jimbo's all about them. http://techcrunch.com/2012/12/10/50-android-smartphones-are-disrupting-africa-much-faster-than-you-think-says-wikipedias-jimmy-wales/ This is a big deal at Mozilla also: http://arstechnica.com/information-technology/2012/07/mozillas-b2g-to-be-called-firefox-os-will-ship-in-2013/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] mariadb 5.5 in production for english wikipedia
On Wednesday, December 12, 2012, David Gerard wrote: On 12 December 2012 15:32, Thomas Fellows thomas.fell...@gmail.comjavascript:; wrote: This is awesome! Is there any write-up of the migration process floating around? +1 In fact, this would be a nice thing to put on the WMF blog. It'll certainly get a lot of linkage and reporting around the geekosphere. A detailed blog post is definitely my intent, I'm just waiting until at least one major project is 100% on mariadb and I have more data and hence confidence in drawn conclusions. I don't think that's far off at all, potentially later this month. If that occurs and goes well, the eqiad data center migration in late January may also be a migration to all mariadb. ___ 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
On Wed, Dec 12, 2012 at 3: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? Fact for consideration: Currently our infrastructure is not set up/able to host originals in the Netherlands. And our storage infrastructure takes more than just one server ;) 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 -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ 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] Alpha version of the VisualEditor now available on the English Wikipedia
Would it be possible to enable VE in a similar manner on other WMF wikis? I understand the concerns about developers being unable to respond to feedback in other languages, but most large projects have at least a few technical people who could serve as relays, and I'd like to see some of the interface improvements start trickling down to projects other than the English Wikipedia. -- Matma Rex ([[:w:pl:User:Matma Rex]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On 12 December 2012 11:57, Andre Klapper aklap...@wikimedia.org wrote: On Tue, 2012-12-11 at 19:30 -0800, James Forrester wrote: This is not the final form of the VisualEditor in lots of different ways. We know of a number of bugs, and we expect you to find more. We do not recommend people trying to use the VisualEditor for their regular editing yet. We would love your feedback on what we have done so far – whether it’s a problem you discovered, an aspect that you find confusing, what area you think we should work on next, or anything else, please do let us know.[1] [1] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback Playing the bad cop who's reading random feedback pages daily: As https://www.mediawiki.org/wiki/VisualEditor/Feedback also exists I wonder if the VisualEditor deployment on en.wp and its related feedback is so different from upstream that it needs a separate feedback page (instead of e.g. a soft redirect to the mw: one), or other reasons. Or does the en.wp one somehow make it easier for testers to report issues? When we deploy VE to other Wikipedias, will there also be separate VE feedback pages (maybe due to the different languages)? Note: I'm not criticizing it, I'm just trying to understand, and I'm picking VE as the most recent example. Thanks in advance for explaining, andre -- You're after a different audience for this alpha test - not the technically confident user who wanders from wiki to wiki and instinctively understands just about any software variation thrown at them, but those whose focus is on editing. Mediawiki wiki uses Liquid threads, which pretty well everyone considers an unacceptable talk page method, and it creates an unnecessary communication barrier for those who just want to report their findings rather than having to figure out a different site's software. And a rather significant number of enwp editors avoid other WMF wikis like the plague for complex sociological reasons. Bottom line, the objective is getting a wide range of editors to test the software through its various functions, identify issues, and report them. Making it as easy as possible for them to do so will produce the best response. Risker ___ 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
On 12 December 2012 17:26, Luke Welling lwell...@wikimedia.org wrote: 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. That's because their interest is in sheer marketshare. Mozilla went proprietary for bad reasons, therefore we should too does not strike me as a convincing argument. We had this exact conversation before. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
Two quotes from the last weeks:
Krenair in #mediawiki on Nov 30 22:46:47:
andre__, what is stopping us from making a 'patch in
gerrit' bug status with a link to the change?
Ryan Kaldari in
https://bugzilla.wikimedia.org/show_bug.cgi?id=42470#c4 :
I use Bugzilla as a to-do list. [...] If Bugzilla had a 'Waiting
for Merge' status, this wouldn't be as much of an issue.
Currently there is a patch-in-gerrit keyword in Bugzilla. When a bug
report ends up as RESOLVED FIXED there usually had been a codefix in
Gerrit that got merged. Hence patch in gerrit could be considered
another state on the journey of a bug from reporting to fixing.
And Bugzilla allows adding stati (stuff like NEW or RESOLVED).
I'm proposing adding a new status like
PATCH_TO_REVIEW or
WAITING_FOR_MERGE or
FIX_AWAITING_MERGE or
REVIEW_IN_PROGRESS
or something like this (bikeshed, yay!). Probably the first.
The status would replace the patch-in-gerrit keyword and you would set
it in Bugzilla when you have pushed a patch into Gerrit for review that
is expected to fix the reported bug. (Not sure what to do about partial
fixes, but that's a cornercase.)
Obviously, once the patch got merged you'd close the corresponding bug
report as RESOLVED FIXED. No changes here.
Bug report life cycle: The new status could be set from {UNCONFIRMED,
NEW, ASSIGNED, REOPENED} and could be transfered into {UNCONFIRMED, NEW,
ASSIGNED, REOPENED, RESOLVED}.
Comments / arguments?
andre
PS: Underscores in the status name are needed as far as I know.
Please keep opinions for other email threads that are about renaming
some other Bugzilla stati, or better linking between Bugzilla and
Gerrit, or automatic status setting in Bugzilla when a patch is in
Gerrit, or somehow distinguishing in Bugzilla between the situations
fix merged into code repository, fix released in MW tarball and fix
deployed on an MW server. I hereby thank you kindly! :)
--
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] Bugzilla: Waiting for merge status when patch is in Gerrit?
Le 12/12/12 19:03, Andre Klapper a écrit : snip I'm proposing adding a new status like PATCH_TO_REVIEW or WAITING_FOR_MERGE or FIX_AWAITING_MERGE or REVIEW_IN_PROGRESS or something like this (bikeshed, yay!). Probably the first. snip I use Bugzilla as a todo list and would love to filter changes that have or dont have a patch in Gerrit. Launchpad.net has instead of RESOLVED and VERIFIED: Fix Committed (fixed but not available until next release) Fix Released (fix released). That let them create release notes out of the bug tracker. In our case I would simply create a single status before RESOLVED that would state there is a patch in Gerrit. We could even imagine changing that state to RESOLVED whenever the patch has been merged. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On 12/12/2012 09:31 AM, Bartosz Dziewoński wrote: Would it be possible to enable VE in a similar manner on other WMF wikis? Currently Parsoid does not support localized namespaces, link trail character classes and other features. Without support for these, pages will not render and round-trip properly. Implementing this is not rocket science, but is currently lower priority than other more urgent tasks. Gabriel -- Gabriel Wicke Senior Software Engineer Wikimedia Foundation ___ 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
As Brion points out, we get much better coverage. I enabled h.264 locally and ran though a set of Android , iOS and desktop browsers I had available at the time: http://www.mediawiki.org/wiki/Extension:TimedMediaHandler/Platform_testing Pro h.264: * No one is proposing turning off webm, an ideological commitment to support free access with free platforms in royalty free formats, does not necessarily require you exclude derivation to proprietary formats. * We already are not ideologically pure ** We submit to the apple store terms of service, we build outputs with non-freedom iOS tool chain etc. ** We write custom code / work arounds to support proprietary non web-standard browsers. * There is little to no chance of Apple adding googles codec support to their platform. * We could ingest h.264 making letting the commons store source material in its originally source captured format. This is important for years down the road we have the highest quality possible. * Chicken and egg, for companies like apple to care about wikimedia webm only support, wikimedia would need lots of video, as long as we don't support h.264 our platform discourages wide use video on articles. Pro Webm: * Royalty free purity in /most/ of what wikimedia distributes. * We could in theory add software playback of webm to our iOS and android app. * Reduced storage costs ( marginal, vs public good of access ) * Reduced licence costs for an h.264 encoder on our two transcoding boxes ( very marginal ) * Risk that mpeg-la adds distribution costs for free online distribution in the future. Low risk, and we could always turn it off --michael On 12/12/2012 11:26 AM, Luke Welling wrote: 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] gerrit support question: how to show raw file content after the commit in the browser, not as zip download
On 12/12/12 4:44 AM, Chad wrote: On Wed, Dec 12, 2012 at 3:09 AM, Ryan Kaldari rkald...@wikimedia.org wrote: I found a solution to the problem: If a gerrit administrator declares the mimetypes of the files to be safe they will be displayed in-browser rather than downloaded as zip files: https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#_a_id_mimetype_a_section_mimetype Could someone edit the gerrit.config file to declare php, javascript, and css files as 'safe'? That doesn't quite work the way you're thinking--it's for us to define mimetypes that Gerrit should show diffs of (rather than a zip download of the file). All text- based filetypes are already shown by the browser as diffs, but most binary filetypes aren't shown on diff. Images originally suffered this problem, but we fixed it[0]. There's not a config switch for what the OP is asking for--but feel free to file a bug upstream[1] :) Are you sure? This doesn't jibe with what the Gerrit developers say in the support forums: https://groups.google.com/forum/#!topic/repo-discuss/h7Bvgns5cyY/discussion Ryan Kaldari ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On Wed, Dec 12, 2012 at 8:57 AM, Andre Klapper aklap...@wikimedia.orgwrote: On Tue, 2012-12-11 at 19:30 -0800, James Forrester wrote: This is not the final form of the VisualEditor in lots of different ways. We know of a number of bugs, and we expect you to find more. We do not recommend people trying to use the VisualEditor for their regular editing yet. We would love your feedback on what we have done so far – whether it’s a problem you discovered, an aspect that you find confusing, what area you think we should work on next, or anything else, please do let us know.[1] [1] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback Playing the bad cop who's reading random feedback pages daily: As https://www.mediawiki.org/wiki/VisualEditor/Feedback also exists I wonder if the VisualEditor deployment on en.wp and its related feedback is so different from upstream that it needs a separate feedback page (instead of e.g. a soft redirect to the mw: one), or other reasons. Or does the en.wp one somehow make it easier for testers to report issues? When we deploy VE to other Wikipedias, will there also be separate VE feedback pages (maybe due to the different languages)? Note: I'm not criticizing it, I'm just trying to understand, and I'm picking VE as the most recent example. Thanks in advance for explaining, andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ Risker said many of the reasons but the biggest reason is that a large portion of testers would not move wiki. Opening up a local spot for feedback drastically increases the amount of feedback you get which can be really helpful. Personally I think we should do it on as many wikis as we can for major projects like this but it's obviously difficult to do on many because of both the language barriers and watching too many feedback channels. Yet another thing that once a product like Echo works cross wiki it could be helpful for :) but that's a bit of a ways away. James James Alexander Manager, Merchandise Wikimedia Foundation (415) 839-6885 x6716 @jamesofur ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] gerrit support question: how to show raw file content after the commit in the browser, not as zip download
On Wed, Dec 12, 2012 at 1:46 PM, Ryan Kaldari rkald...@wikimedia.org wrote: On 12/12/12 4:44 AM, Chad wrote: On Wed, Dec 12, 2012 at 3:09 AM, Ryan Kaldari rkald...@wikimedia.org wrote: I found a solution to the problem: If a gerrit administrator declares the mimetypes of the files to be safe they will be displayed in-browser rather than downloaded as zip files: https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#_a_id_mimetype_a_section_mimetype Could someone edit the gerrit.config file to declare php, javascript, and css files as 'safe'? That doesn't quite work the way you're thinking--it's for us to define mimetypes that Gerrit should show diffs of (rather than a zip download of the file). All text- based filetypes are already shown by the browser as diffs, but most binary filetypes aren't shown on diff. Images originally suffered this problem, but we fixed it[0]. There's not a config switch for what the OP is asking for--but feel free to file a bug upstream[1] :) Are you sure? This doesn't jibe with what the Gerrit developers say in the support forums: https://groups.google.com/forum/#!topic/repo-discuss/h7Bvgns5cyY/discussion Yes, I'm pretty sure. That thread is confusing. Before we enabled this for images, you used to have to download images as a zip rather than in diffs. I'm pretty sure it has no affect on the download buttons serving zips on those pages...but we can test. See bug 36852[0] for history. Also fun is which mimetypes to use[1] ;-) -Chad [0] https://bugzilla.wikimedia.org/show_bug.cgi?id=36852 [1] http://cweiske.de/tagebuch/php-mimetype.htm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On Tue, Dec 11, 2012 at 10:55 PM, Lee Worden worden@gmail.com wrote: Very exciting - congratulations! I know these are early days for the VisualEditor, but is there a plan for extension developers to be able to hook in to provide editing for the things their extensions support? Yes, absolutely! We've been working on cleaning up and rewriting various internal APIs in VE such that they can reasonably be used to write extensions. We've made progress, but we're not done yet, and more recently it's received less attention because of yesterday's release. We're gonna be picking that work back up in January, and once it's done, we would be happy to work with willing guinea pigs to test our APIs in the wild and work out the remaining kinks. As for when that'll actually be scheduled to happen, I defer to James F. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] gerrit support question: how to show raw file content after the commit in the browser, not as zip download
On Tue, Dec 11, 2012 at 10:47 AM, Ryan Kaldari rkald...@wikimedia.org wrote: This is actually my biggest annoyance with gerrit—that I can't view raw code from the change view. I can't fathom why they have a zip download link, but not a view link. Then I could copy code without copying all the line numbers. +1 this is a huge pain point for me too. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] gerrit support question: how to show raw file content after the commit in the browser, not as zip download
On Tue, Dec 11, 2012 at 10:47 AM, Ryan Kaldari rkald...@wikimedia.org wrote: This is actually my biggest annoyance with gerrit—that I can't view raw code from the change view. I can't fathom why they have a zip download link, but not a view link. Then I could copy code without copying all the line numbers. +1 this is a huge pain point for me too. +1 as well. The zip download is weird for a code review tool :) Subbu. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
Lee Worden worden@gmail.com wrote: is there a plan for extension developers to be able to hook in to provide editing for the things their extensions support? Roan Kattouw responded: Yes, absolutely! We've been working on cleaning up and rewriting various internal APIs in VE such that they can reasonably be used to write extensions. Will the method for hooking into VE be the same as for WikiEditor? Or will extension developers need to support both editors in two different ways? Thanks, DanB ___ 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
Original thread from March starts here: http://comments.gmane.org/gmane.science.linguistics.wikipedia.technical/59684 As I noted back then, this is a drastic policy change that needs a lot wider discussion, including on the wikis, than just wikitech-l. On 12 December 2012 18:38, Michael Dale md...@wikimedia.org wrote: * No one is proposing turning off webm, an ideological commitment to support free access with free platforms in royalty free formats, does not necessarily require you exclude derivation to proprietary formats. This proposal is not about anything other than enhancing the shiny for owners of iOS devlces. While the devices are indisputable really lovely to use, this particular (shrinking) userbase does not constitute a group in any way lacking in access to anything we do, on any other device they own (and they do own other devices). The only reason you can't view anything other than H.264 on iOS devices is because Apple want to promote a given severely proprietary format on their locked-down devices. This is not a reason for Wikimedia to break principle. Mozilla is not an argument. Mozilla doing the wrong thing for directly commercial reasons is not any sort of argument for us to. It's only pressure from users that will get the companies to use unlocked formats. * We could ingest h.264 making letting the commons store source material in its originally source captured format. This is important for years down the road we have the highest quality possible. Ingestion is an *entirely* separate issue, as I pointed out last time around - it is erroneous to conflate it with output. (We should be ingesting absolutely anything we can.) * Chicken and egg, for companies like apple to care about wikimedia webm only support, wikimedia would need lots of video, as long as we don't support h.264 our platform discourages wide use video on articles. This claim makes no sense unless you are conflating ingestion and output. We need more video on Wikimedia from every source we can (including, per that other thread, the cheap Android mobile phones of people in Africa), but that has *nothing* to do with whether we output H.264 for the benefit of those who have chosen to use locked-down iOS devices. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
There's also the question of released in tarball vs deployed on Wikipedia. A lot of people just care about the latter. And about the original question - I support the idea and don't care how is it called. בתאריך 12 בדצמ 2012 20:14, מאת Antoine Musso hashar+...@free.fr: Le 12/12/12 19:03, Andre Klapper a écrit : snip I'm proposing adding a new status like PATCH_TO_REVIEW or WAITING_FOR_MERGE or FIX_AWAITING_MERGE or REVIEW_IN_PROGRESS or something like this (bikeshed, yay!). Probably the first. snip I use Bugzilla as a todo list and would love to filter changes that have or dont have a patch in Gerrit. Launchpad.net has instead of RESOLVED and VERIFIED: Fix Committed (fixed but not available until next release) Fix Released (fix released). That let them create release notes out of the bug tracker. In our case I would simply create a single status before RESOLVED that would state there is a patch in Gerrit. We could even imagine changing that state to RESOLVED whenever the patch has been merged. -- 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] Alpha version of the VisualEditor now available on the English Wikipedia
On Wed, Dec 12, 2012 at 11:32 AM, Daniel Barrett d...@vistaprint.com wrote: Will the method for hooking into VE be the same as for WikiEditor? Or will extension developers need to support both editors in two different ways? It won't be the same as for WikiEditors, because the two are very fundamentally different. WikiEditor gives you a toolbar that allows you to insert and manipulate wikitext. VisualEditor gives you something similar (a toolbar that allows you to insert and manipulate rich content), but it also gives you inspectors with pop-up dialogs, toolbar buttons that can change state depending on what's selected, and much more. You can also add new *types* of content, change how content is rendered, etc. The possibilities are endless compared to WikiEditor. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On 12/11/2012 07:30 PM, James Forrester wrote: TL;DR: Today we are launching an alpha, opt-in version of the VisualEditor[0] to the English Wikipedia. This will let editors create and modify real articles visually, using a new system where the articles they edit will look the same as when you read them, and their changes show up as they type enter them — like writing a document in a word processor. Please let us know what you think[1]. Congratulations! I've enabled it, and I can see the existing form is already useful for some workflows. I look forward to providing feedback, and towards the gaps getting filled in. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On 12/12/2012 11:08 AM, Roan Kattouw wrote: On Tue, Dec 11, 2012 at 10:55 PM, Lee Worden worden@gmail.com wrote: Very exciting - congratulations! I know these are early days for the VisualEditor, but is there a plan for extension developers to be able to hook in to provide editing for the things their extensions support? Yes, absolutely! We've been working on cleaning up and rewriting various internal APIs in VE such that they can reasonably be used to write extensions. We've made progress, but we're not done yet, and more recently it's received less attention because of yesterday's release. We're gonna be picking that work back up in January, and once it's done, we would be happy to work with willing guinea pigs to test our APIs in the wild and work out the remaining kinks. As for when that'll actually be scheduled to happen, I defer to James F. I would definitely be willing to serve as a guinea pig, working to integrate ProveIt (http://en.wikipedia.org/wiki/User:ProveIt_GT). Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tutorial videos slides on Puppet, security, performance profiling, i18n, RL, extensions, Lua...
On 12/08/2012 06:59 PM, Sumana Harihareswara wrote: Can someone help me out by wiki-gnoming the videos and slides referenced below, plus those in https://www.mediawiki.org/wiki/Category:Tutorials ? Not-me-not-now but just in case I added those links to https://www.mediawiki.org/wiki/Category_talk:Tutorials#Material_to_categorize to avoid losing them in the list archives. and I also added an entry to my (long) waiting list: https://www.mediawiki.org/wiki/User:Qgil#Task_list All the better if someone decides to jump on this entertaining task before. -- 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] Bugzilla: Waiting for merge status when patch is in Gerrit?
My 2cif we add a new status, it should equate to deployed on the cluster, along with judicious use of milestone so that people who are just interested in the tarball can infer from our numbering what the corresponding release will be. The more statuses (statii?) we add, the less likely they'll actually be a source of actual information. That said, I know that many developers get confused about when they should mark things fixed, and hold off on doing so because things just get reopened with hey, it's still broken for me. I'd like the developers to be able to mark things off of their list when they're done with them, and the rest of us to worry about communicating when the fix is actually released/deployed or is otherwise relevant to them. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On Wed, Dec 12, 2012 at 11:32 AM, Daniel Barrett d...@vistaprint.comwrote: Will the method for hooking into VE be the same as for WikiEditor? Or will extension developers need to support both editors in two different ways? In general they are both conceptually and technically incompatible. Here's some more detail about why: - Wrapping selections in wikitext doesn't really make sense in VisualEditor due to the nature of it's data structures[1]. - The VisualEditor API is not complete yet, but it's designed to make it easy to create new extensions, but also easy to reuse parts of other extensions - an area in particular where WikiEditor was flawed. - Trevor [1] http://www.mediawiki.org/wiki/VisualEditor/Software_design#Data_Structures ___ 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] Bugzilla: Waiting for merge status when patch is in Gerrit?
2012/12/12 Rob Lanphier ro...@wikimedia.org: The more statuses (statii?) we add, statūs, if I recall correctly. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
I would love this status. I'd suggest calling it PENDING I could imagine states: PENDING On Wed, Dec 12, 2012 at 12:34 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: 2012/12/12 Rob Lanphier ro...@wikimedia.org: The more statuses (statii?) we add, statūs, if I recall correctly. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On 12/12/2012 12:44 PM, Jon Robson wrote: I would love this status. I'd suggest calling it PENDING I could imagine states: PENDING I'd prefer something more specific. I actually think PATCH_IN_GERRIT (the keyword) would work well as a status. Matt Flaschen ___ 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
On 12 December 2012 11:44, Antoine Musso hashar+...@free.fr wrote: 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. If anyone owning a chunk of H.264 had a problem with Wikimedia doing things with H.264 in the US, it could only be bad for them. I would suggest this aspect isn't really a problem. - d. ___ 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
On Wed, Dec 12, 2012 at 11:35 AM, David Gerard dger...@gmail.com wrote: Original thread from March starts here: http://comments.gmane.org/gmane.science.linguistics.wikipedia.technical/59684 As I noted back then, this is a drastic policy change that needs a lot wider discussion, including on the wikis, than just wikitech-l. Hi folks, The WMF Legal team is evaluating the license now to inform this decision. I don't have an ETA for this since they're a little shortstaffed right now and we're heading into the holidays. Rob ___ 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
On 12/11/2012 03:02 PM, Brion Vibber wrote: However, every other mobile browser I've tested doesn't support Ogg Theora or WebM formats. Mobile Safari, Chrome, the old stock Android browser, Opera Mobile, and the IE 10 engine in our Windows 8 tablet app will show the thumbnail, but won't play the video because they need MP4/H.264. Did you test WebM in Android Browser 2.3+ or Chrome for Android 18+ (I think this is latest). http://caniuse.com/webm says those support WebM, but I have not verified. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
I think we could have different types of pending - pending design pending review pending legal etc etc. Maybe this is out of scope though..? On Dec 12, 2012 12:55 PM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 12/12/2012 12:44 PM, Jon Robson wrote: I would love this status. I'd suggest calling it PENDING I could imagine states: PENDING I'd prefer something more specific. I actually think PATCH_IN_GERRIT (the keyword) would work well as a status. 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] Alpha version of the VisualEditor now available on the English Wikipedia
From: Roan Kattouwroan.katt...@gmail.com On Tue, Dec 11, 2012 at 10:55 PM, Lee Wordenworden@gmail.com wrote: Very exciting - congratulations! I know these are early days for the VisualEditor, but is there a plan for extension developers to be able to hook in to provide editing for the things their extensions support? Yes, absolutely! We've been working on cleaning up and rewriting various internal APIs in VE such that they can reasonably be used to write extensions. We've made progress, but we're not done yet, and Fantastic! more recently it's received less attention because of yesterday's release. Of course. We're gonna be picking that work back up in January, and once it's done, we would be happy to work with willing guinea pigs to test our APIs in the wild and work out the remaining kinks. As for when that'll actually be scheduled to happen, I defer to James F. Roan Great! I'll stay tuned. Great work! Lee ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mobile apps: time to go native?
On Tue, Dec 11, 2012 at 4:35 PM, Brion Vibber bvib...@wikimedia.org wrote: Any thoughts? Wildly in favor or against? From Brion's original email as well as my perspective from being involved in these projects, I am in favor of shifting to native code for iOS and Android. Considering the goals of the mobile team for 2012/2013 [1] include building contributory features (beyond basic editing and even beyond just uploading photos [and while certainly some mobile devices have terrible cameras, many have exceptional cameras]), the fact that we've been thinking about contributory pipelines that involve multiple devices, and the fact that we've had headaches building contributory features using Cordova, shifting to a native codebase for the most used mobile platforms makes a LOT of sense. One argument that could be made against shifting to a native codebase for the android/iOS apps is that of accessibility to our engineering community. The great thing about Cordova is the fact that 99% of what you need to know to dive in is HTML and JS. However, we do have Java devs and Objective C devs in the community - and creating more things in those language could also help attract other engineers who like to focus on that kind of stuff into our community. Overall, I think the benefits far outweigh the potential drawbacks. [1] http://www.mediawiki.org/wiki/Wikimedia_Engineering/2012-13_Goals#Mobile -- 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
Re: [Wikitech-l] Video on mobile: Firefox works, way is paved for more browser support
On Wed, Dec 12, 2012 at 1:04 PM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 12/11/2012 03:02 PM, Brion Vibber wrote: However, every other mobile browser I've tested doesn't support Ogg Theora or WebM formats. Mobile Safari, Chrome, the old stock Android browser, Opera Mobile, and the IE 10 engine in our Windows 8 tablet app will show the thumbnail, but won't play the video because they need MP4/H.264. Did you test WebM in Android Browser 2.3+ or Chrome for Android 18+ (I think this is latest). http://caniuse.com/webm says those support WebM, but I have not verified. I was able to play the WebM file of the locomotive on the front page of https://commons.wikimedia.org just now on my Nexus 7 using Chrome, so at least on very new stock Android devices, all is well. My much older Galaxy S didn't fare so well, though, so I would be willing to believe that Android devices with proper WebM support are still relatively rare. That said, the replacement rate for this hardware is frequent enough that it won't be long before my Nexus 7 is much older. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Proposal: MediaWiki Group San Francisco
Hi, following the process for requesting the creation of a MediaWiki group, here is a proposal for MediaWiki Group San Francisco http://www.mediawiki.org/wiki/Groups/Proposals/San_Francisco Your endorsements, improvements and feedback are welcome at the wiki page. Thank you! -- 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] gerrit support question: how to show raw file content after the commit in the browser, not as zip download
I started this thread. I filed this bug https://bugzilla.wikimedia.org/show_bug.cgi?id=42989 Gerrit: show link for raw file content in gerrit diff views (a solution is proposed inside) It has been closed as RESOLVED INVALID instead of deploying a solution to Gerrit. As a solution of the problem (show a raw file content) has not been found (GitHub shows raw file contents, SVN browser ViewVC shows raw file contents) example https://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/AJAXPoll/AJAXPoll.php?revision=114166view=co I feel unhappy. Very unhappy. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On Wed, Dec 12, 2012 at 7:03 PM, Andre Klapper aklap...@wikimedia.org wrote: Two quotes from the last weeks: Krenair in #mediawiki on Nov 30 22:46:47: andre__, what is stopping us from making a 'patch in gerrit' bug status with a link to the change? Ryan Kaldari in https://bugzilla.wikimedia.org/show_bug.cgi?id=42470#c4 : I use Bugzilla as a to-do list. [...] If Bugzilla had a 'Waiting for Merge' status, this wouldn't be as much of an issue. Currently there is a patch-in-gerrit keyword in Bugzilla. When a bug report ends up as RESOLVED FIXED there usually had been a codefix in Gerrit that got merged. Hence patch in gerrit could be considered another state on the journey of a bug from reporting to fixing. And Bugzilla allows adding stati (stuff like NEW or RESOLVED). ASSIGNED seems perfect for me. It's ASSIGNED, this mean there are work going to be done, or done. Gerrit gives the detail. We already have problems to get all the developers to used ASSIGNED field, let's avoid to complicate with other fields, with a rather limited purpose scope. I would also like to stress the assumption 1 issue = 1 bug on Bugzilla = 1 patch on Gerrit isn't verified in real world. This idea completely blocks any situation where two patches or a patch and then a configuration on the wiki has to occur to solve the bug. For what goal? - Compute statistics -- we could get them from Gerrit - Identify patches waiting to be merged - that's exactly the goal of the Gerrit dashboard For what drawbacks? - Less flexibility - Greater bug handling learning curve I would really like to get our bugs system simple (KISS) and not to clutter with not needed features. -- Best Regards Sébastien Santoro aka Dereckson http://www.dereckson.be/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] gerrit support question: how to show raw file content after the commit in the browser, not as zip download
On 12/12/2012 03:26 PM, Thomas Gries wrote: I started this thread. I filed this bug https://bugzilla.wikimedia.org/show_bug.cgi?id=42989 Gerrit: show link for raw file content in gerrit diff views (a solution is proposed inside) It has been closed as RESOLVED INVALID instead of deploying a solution to Gerrit. Ryan said Chad will test the suggested config change, and if that doesn't work, Ryan will talk to the Gerrit devs. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On 12/12/2012 04:15 PM, Sébastien Santoro wrote: Currently there is a patch-in-gerrit keyword in Bugzilla. When a bug report ends up as RESOLVED FIXED there usually had been a codefix in Gerrit that got merged. Hence patch in gerrit could be considered another state on the journey of a bug from reporting to fixing. And Bugzilla allows adding stati (stuff like NEW or RESOLVED). ASSIGNED seems perfect for me. It's ASSIGNED, this mean there are work going to be done, or done. That doesn't make sense to me, since I can be assigned something, and actively working on it, but not have submitted a Gerrit at all yet (let alone one almost ready to be merged). Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On Dec 13, 2012, at 1:25 AM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 12/12/2012 04:15 PM, Sébastien Santoro wrote: Currently there is a patch-in-gerrit keyword in Bugzilla. When a bug report ends up as RESOLVED FIXED there usually had been a codefix in Gerrit that got merged. Hence patch in gerrit could be considered another state on the journey of a bug from reporting to fixing. And Bugzilla allows adding stati (stuff like NEW or RESOLVED). ASSIGNED seems perfect for me. It's ASSIGNED, this mean there are work going to be done, or done. That doesn't make sense to me, since I can be assigned something, and actively working on it, but not have submitted a Gerrit at all yet (let alone one almost ready to be merged). Matt Flaschen I agree with Sébastien. ASSIGNED is enough. I don't see the significance of whether there is a Gerrit change yet? If there is no Gerrit change, it doesn't mean nobody is working on it. And if there is a change, it may not be a good one and/or one written by someone else (e.g. someone else can give it a try, send the change-id to bugzilla, but the assignee hasn't reviewed it yet and/or abandoned it). Then we'd have to keep that in sync (back from this PENDING to ASSIGNED after the change is rejected?). Only more maintenance and bureaucracy for imho no obvious gain or purpose. The queryable state is ASSIGNED (and maybe, though I personally don't find it useful, the keyword patch-in-gerrit). And for any further details just open the bug and read it. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On 12/12/2012 05:09 PM, Krinkle wrote: I agree with Sébastien. ASSIGNED is enough. I don't see the significance of whether there is a Gerrit change yet? If there is no Gerrit change, it doesn't mean nobody is working on it. And if there is a change, it may not be a good one and/or one written by someone else (e.g. someone else can give it a try, send the change-id to bugzilla, but the assignee hasn't reviewed it yet and/or abandoned it). People can look for the PATCH_IN_GERRIT status to find things to review. As you say, some changes are good, some are not. This is another way to attract reviewers to Gerrit changes. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On 12/12/12 21:23, Rob Lanphier wrote: My 2cif we add a new status, it should equate to deployed on the cluster, along with judicious use of milestone so that people who are just interested in the tarball can infer from our numbering what the corresponding release will be. On which wiki? We could have it deployed on part of the cluster only. The difference is between Waiting for merge and Fixed. Once it is fixed, the landing is automatic, from the commit hash, there could be a tool which showed you if it's on wmfxy, on which tarball release it will appear, if you can see the fix in test2, to which wikis it's deployed and approximate time for deployment to your home wiki. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Waiting for merge status when patch is in Gerrit?
On Thu, Dec 13, 2012 at 2:27 AM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 12/12/2012 05:09 PM, Krinkle wrote: I agree with Sébastien. ASSIGNED is enough. I don't see the significance of whether there is a Gerrit change yet? If there is no Gerrit change, it doesn't mean nobody is working on it. And if there is a change, it may not be a good one and/or one written by someone else (e.g. someone else can give it a try, send the change-id to bugzilla, but the assignee hasn't reviewed it yet and/or abandoned it). People can look for the PATCH_IN_GERRIT status to find things to review. As you say, some changes are good, some are not. This is another way to attract reviewers to Gerrit changes. The Gerrit dashboard prints the first line of the change, which should begin by (bug 12345). So your view Bugs to review already exists in Gerrit dashboard. -- Best Regards, Sébastien Santoro aka Dereckson http://www.dereckson.be/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
On Wed, Dec 12, 2012 at 12:14 PM, Matthew Flaschen mflasc...@wikimedia.org wrote: I would definitely be willing to serve as a guinea pig, working to integrate ProveIt (http://en.wikipedia.org/wiki/User:ProveIt_GT). Awesome! Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
