Re: [Wikitech-l] VE in 1.23? (was: Mozilla's Wiki Working Group meeting Tues 1600 UTC)
On May 6, 2014 12:12 AM, David Gerard dger...@gmail.com wrote: On 5 May 2014 23:08, James Forrester jforres...@wikimedia.org wrote: On 5 May 2014 15:05, David Gerard dger...@gmail.com wrote: So ... how is 1.23 and Visual Editor? * Has anyone sat down and written out how to add VE magic to a 1.23 tarball install? I do not believe so, no. If someone could do that, I hereby promise to beta-test their instructions! (Personally, I think VE is pretty much ready for all users except English Wikipedia.) - d. You would be wrong. There are still many scripts unsupported, that result in a horribly broken VE experience. That said, making it dead easy to install everything for a Wikimedia with VE seems like a reasonable priority at this point. -Martijn ___ 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] recent changes stream
On Mon, May 5, 2014 at 7:36 PM, Petr Bena benap...@gmail.com wrote: I said this once in a gerrit comment and I will say it here as well: most of people have different opinion on what is good for them as RC stream. We should go for anything specific, but rather for a very abstract solution that could be multiplexed into multiple RC feed providers using a number of popular formats (including this IRC format just for backward compatibility). So in the end, users would be able to pick what format and protocol they want, just as they can do that with api.php Ideal RC stream would be so flexible that it could match any possible use case. Standard solutions seem to be things like rabbitMQ/zeroMQ/activeMQ/lolbiztalk Websockets seems like something that should work, but is something of a square peg/round hole thing. It needs a http connection to upgrade from which is just unnatural for this problem, and is intended to be consumed by client side javascript in browsers which communicate to a server. On Mon, May 5, 2014 at 6:45 PM, Erik Bernhardson ebernhard...@wikimedia.org wrote: I think we need to be clearer about what the goal is here, as is I think we are all taking our personal idea of what we want to do with a feed and applying that to this implementation. Personally I have been working on an external watchlist service that i would love to hook up to a feed, but without any guarantees of receiving every single event my particular use case is better off continuously scanning the xml feeds of 800 wikis. I'm certain other people are thinking of completely different things as well. Erik B. On Mon, May 5, 2014 at 2:29 AM, Petr Bena benap...@gmail.com wrote: Given the current specifications I can only support this change as long as current IRC feed is preserved as IRC is IMHO, as much as evil it looks, more suitable for this than WebSockets. I am not saying that IRC is suitable for this and I know that people really wanted to get rid of it or replace it with something better, but I just can't see how is this better. On Mon, May 5, 2014 at 10:37 AM, Daniel Kinzler dan...@brightbyte.de wrote: Am 05.05.2014 07:20, schrieb Jeremy Baron: On May 4, 2014 10:24 PM, Ori Livneh o...@wikimedia.org wrote: an implementation for a recent changes stream broadcast via socket.io, an abstraction layer over WebSockets that also provides long polling as a fallback for older browsers. [...] How could this work overlap with adding pubsubhubbub support to existing web RC feeds? (i.e. atom/rss. or for that matter even individual page history feeds or related changes feeds) The only pubsubhubbub bugs I see atm are https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=38970%2C30245 There is a Pubsubhubbub implementation in the pipeline, see https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FPubSubHubbub. It's pretty simple and painless. We plan to have this deployed experimentally for wikidata soon, but there is no reason not to roll it out globally. This implementation uses the job queue - which in production means redis, but it's pretty generic. As to an RC *stream*: Pubsubhubbub is not really suitable for this, since it requires the subscriber to run a public web server. It's really a server-to-server protocol. I'm not too sure about web sockets for this either, because the intended recipient is usually not a web browser. But if it works, I'd be happy anyway, the UDP+IRC solution sucks. Some years ago, I started to implement an XMPP based RC stream, see https://www.mediawiki.org/wiki/Extension:XMLRC. Have a look and steal some ideas :) -- daniel ___ 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 ___ 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] Phabricator RFC Closed Next Steps
Hi, == Closing the Phabricator RFC == As previously announced [1], we've been facilitating an RFC proposing to replace Wikimedia's current product management tools and development toolchain by a tool called Phabricator: https://www.mediawiki.org/wiki/Requests_for_comment/Phabricator We'd like to thank everybody for discussing and testing Phabricator and providing very helpful feedback for the last three weeks! In order to move forward and avoid letting the RFC be forgotten in a dusty corner of the wiki, it's now time to close and summarize it. The goal of the RFC was to gauge interest in simplifying our development toolchain and consolidating our tools (gitblit, Gerrit, Jenkins, Bugzilla, RT, Trello, and Mingle) into Phabricator. At first glance, it seems that there is support for this proposal. The consensus is also that there are blockers that must be addressed before any migration is considered, and that any migration must be carefully planned and as carefully executed. To be clear: It's not yet been decided to move to Phabricator. The RFC has shown that there is interest and enthusiasm about Phabricator, and this means resources could now be devoted to work more specifically on the blockers and the migration plan. We expect that there will be another (shorter) discussion down the road to serve as a reality check. Its format will be lighter than that of the RFC, since its goal will mostly to check that blockers have been resolved and the migration plan makes sense. == Plan for blockers and migration == A first phase of the migration would focus on migrating all the Bugzilla data to Phabricator, and merging the project management work being done in Trello and Mingle. A second phase —that could be worked in parallel— would focus on substituting Gerrit for code review, and RT. There is also a possibility to deprecate Jenkins as a continuous integration tool, but this option is out of scope for now. A few blockers have been identified in these areas, and we will collaborate with the Phabricator community to fix them. The schedule for this migration depends on resolving those issues which are blockers for Wikimedia moving to Phabricator. The Engineering Platform team at the Wikimedia Foundation would lead this project allocating the resources necessary to define a detailed plan, proceed with the migration, and maintain the new infrastructure. A longer version, requirements to still sort out first, and concerns raised have been summarized by Quim at https://www.mediawiki.org/wiki/Requests_for_comment/Phabricator/Plan == Join the next discussions == There will be a session about Phabricator at the Wikimedia hackathon in Zürich this week-end (see [2]), as well as another IRC discussion next week (in #wikimedia-office on Wednesday, May 14, at 18:00 UTC: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Phabricator+migration+planning+IRC+discussioniso=20140514T20p1=329ah=1 ) Cheers, Guillaume and Andre (and Quim) [1] http://lists.wikimedia.org/pipermail/wikitech-l/2014-April/075993.html [2] https://www.mediawiki.org/wiki/Z%C3%BCrich_Hackathon_2014/Topics#Future_of_version_control.2C_bug_reporting_and_other_developer_tools -- 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] [Engineering] Help! Phabricator and our code review process
On Mon, May 5, 2014 at 10:24 PM, Matthew Flaschen mflasc...@wikimedia.orgwrote: On 05/02/2014 03:56 PM, C. Scott Ananian wrote: [greg-g] cscott: James_F crazy idea here: can some teams use it for real (I think growth is, kinda?) and export/import to a future real instance? frontend... No, we're not using it for real currently. We (Growth) have talked about potentially being an early adopter, but have not committed to this yet. Matt Flaschen Likewise for Analytics ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Travelling Labs!
Hey all, Me and Andrew Bogott will be travelling to Zürich for the Hackaton[1] in the coming days; this means limited online availability during actual travel time, but vastly increased physical availability in Zürich itself. :-) I will be available for help in porting tools to the Tool Labs, helping maintainers debug or improve their tools, or for any other labs-related task for the duration of the Hackaton. Don't hesitate to drop by and say hi, even if you don't need my help with anything! After the Hackaton, I'm taking a few day's worth of vacation, and will return to full availability starting May 16th. -- Marc [1] https://www.mediawiki.org/wiki/Zürich_Hackathon_2014 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Minutes and slides from the Release Engineering and QA quarterly review
Minutes and slides from the quarterly review meeting with the Wikimedia Foundation's Release Engineering and QA team on April 30 have been posted here: https://www.mediawiki.org/wiki/Wikimedia_Release_and_QA_Team/Quarterly_review,_April_2014/Notes -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Labs-l] Travelling Labs!
Looking forward to drinking beer with you guys :3 On Tue, May 6, 2014 at 7:25 PM, Marc A. Pelletier m...@uberbox.org wrote: Hey all, Me and Andrew Bogott will be travelling to Zürich for the Hackaton[1] in the coming days; this means limited online availability during actual travel time, but vastly increased physical availability in Zürich itself. :-) I will be available for help in porting tools to the Tool Labs, helping maintainers debug or improve their tools, or for any other labs-related task for the duration of the Hackaton. Don't hesitate to drop by and say hi, even if you don't need my help with anything! After the Hackaton, I'm taking a few day's worth of vacation, and will return to full availability starting May 16th. -- Marc [1] https://www.mediawiki.org/wiki/Zürich_Hackathon_2014 ___ Labs-l mailing list lab...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/labs-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikimedia Hackathon grid
Wikimedia Hackathon participants, please have a look at https://www.mediawiki.org/wiki/Zürich_Hackathon_2014/Schedule It is an almost empty grid with very few exceptions. It is based on the idea of beginning of the day with 1h slots for planning, and then defaulting to 1h30 slots, following the advice of many participants in Amsterdam last year. There are some basic principles proposed, everything debatable. If you have especial requirements for your session (e.g. local or remote guests that need to know the time in advance) then you can start discussing them in the Talk page. The idea is to do most of the scheduling on Friday morning, then fine tune as we go. On Friday morning we will use the /Topics page to organize the scheduling, starting with the topics that have raised more interest: https://www.mediawiki.org/wiki/Zürich_Hackathon_2014/Topics You are welcome to create wiki subpages and/or etherpads ( https://etherpad.wikimedia.org/ ) for your activities. We will have a process for session coordinators to create hangouts from the MediaWiki Google+ page, in order to have low-tech instant streaming and videos archived, all from your laptops. -- Quim Gil Engineering Community Manager @ 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
