Re: [Wikitech-l] Gerrit actively discourages discussion
Thanks for bringing this up MZ. I completely agree with you. The amount of times I've had to link people on irc to a comment to see it is ridiculous. I'm not sure what the exact solution is but I feel we need to improve it in gerrit itself rather than move to bugzilla. On Mon, Apr 1, 2013 at 7:39 PM, MZMcBride z...@mzmcbride.com wrote: Hi. I'm concerned that Gerrit actively discourages discussion currently. I see a few issues: * auto-collapsing all comments except the most recent; * no reply feature or support for quoting (similar to what Bugzilla uses); and * the add comment feature doesn't allow you to write a comment while viewing the code or viewing the other comments, resulting in an awful workflow for me when attempting to write a comment. Is there some way to address these issues? Would it make sense to move all discussion back to Bugzilla? Is there some way to adjust Gerrit's behavior here? Or perhaps I'm the only one who finds this problematic. MZMcBride ___ 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] Gerrit actively discourages discussion
Le 02/04/13 04:39, MZMcBride a écrit : I'm concerned that Gerrit actively discourages discussion currently. So do not use it? We have lists, wiki and private emails. I see a few issues: * auto-collapsing all comments except the most recent; * no reply feature or support for quoting (similar to what Bugzilla uses); and * the add comment feature doesn't allow you to write a comment while viewing the code or viewing the other comments, resulting in an awful workflow for me when attempting to write a comment. The basic misconception is that people attempt to comment the code using the 'cover message' feature when they should really use the inline commenting feature. The cover message is only intended to summarize what you have commented inline, that is also what is shown in the mail notification. When doing inline comments, they are shown in the diff. So if one commented on patchset 2 and is willing to find out whether his suggestion has been achieved, he could use the PS2 as a basis for a diff. All his comments will be shown as well as the following up changes. When I amend a patchset, I will use the [Done] button on each change to confirm the reviewers that I have corrected the issues. Is there some way to address these issues? Would it make sense to move all discussion back to Bugzilla? Is there some way to adjust Gerrit's behavior here? Or perhaps I'm the only one who finds this problematic. I would prefer having all the code and implementations discussion where the code is, aka in Gerrit. Leaving Bugzilla for confirming the bug resolution or talk about possible policy issues. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit actively discourages discussion
Hi, while I do not want to discourage discussion of those items on wikitech-l, I nevertheless filed them in bugzilla, so we can keep track of the issues / solutions. On Mon, Apr 01, 2013 at 10:39:50PM -0400, MZMcBride wrote: * auto-collapsing all comments except the most recent; https://bugzilla.wikimedia.org/show_bug.cgi?id=46774 * no reply feature or support for quoting (similar to what Bugzilla uses); https://bugzilla.wikimedia.org/show_bug.cgi?id=46776 * the add comment feature doesn't allow you to write a comment while viewing the code or viewing the other comments, resulting in an awful workflow for me when attempting to write a comment. https://bugzilla.wikimedia.org/show_bug.cgi?id=46777 Best regards, Christian -- quelltextlich e.U. \\ Christian Aistleitner Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65aEmail: christ...@quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax:+43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --- signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Proposal: Wikitech contributors
I have been drafting a proposal to attract new contributors, help them settle in, and connect them to interesting tasks. It turns out that many of these problems are not unique to new contributors. We suffer them as well and we are just used to them. The proposal has evolved into a deeper restructuring of our community spaces. We're still drafting it, but a round of wider feedback is welcome before opening the official RFC at https://www.mediawiki.org/wiki/Requests_for_comment/Wikitech_contributors In summary: * wikitech.wikimedia.org would become the one and only site for our open source software contributors, powered by semantic software and an ontology of categories shared across wiki pages, Bugzilla and hopefully Gerrit. * Semantic user profiles would identify interests, project membership and preferences so users could get notifications about specific topics. * Nodes would automatically structure links to the key information about a specific topic: wiki pages, events, news, projects, bug reports, Gerrit changesets, related contributors, and people interested. * All project teams, whoever is in them, would have a standard way to report goals, members, tasks and updates. The proposal includes a draft plan for a first iteration, including contracting out some software development and redesigning part of wikitech and mediawiki.org. Your feedback is welcome at the discussion page. I will be consolidating there any feedback received here or through other channels. The official RFC should follow pretty soon, maybe next week. -- 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 actively discourages discussion
Antoine Musso wrote: Le 02/04/13 04:39, MZMcBride a écrit : I'm concerned that Gerrit actively discourages discussion currently. So do not use it? We have lists, wiki and private emails. [...] I would prefer having all the code and implementations discussion where the code is, aka in Gerrit. Leaving Bugzilla for confirming the bug resolution or talk about possible policy issues. You're being a little silly here. :-) I think I agree with you that keeping the change and the related discussion together would be nice. The question is: how do we make Gerrit less painful to use? Would it be possible to have Gerrit import a JavaScript page from MediaWiki.org (e.g., MediaWiki:Gerrit.js)? This might allow dedicated users to override some of the default behavior (such as the block-level comment auto-collapsing) or add new functionality (such as a reply link similar to Bugzilla's). The basic misconception is that people attempt to comment the code using the 'cover message' feature when they should really use the inline commenting feature. The cover message is only intended to summarize what you have commented inline, that is also what is shown in the mail notification. Gerrit supports both inline commenting and block-level commenting. The inline commenting is actually even more difficult to find and follow than block-level commenting, in my opinion. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit actively discourages discussion
On Tue, Apr 2, 2013 at 9:03 AM, MZMcBride z...@mzmcbride.com wrote: Would it be possible to have Gerrit import a JavaScript page from MediaWiki.org (e.g., MediaWiki:Gerrit.js)? This might allow dedicated users to override some of the default behavior (such as the block-level comment auto-collapsing) or add new functionality (such as a reply link similar to Bugzilla's). There's functionality to write custom Javascript and inject it within Gerrit. So yes, we could easily have our own JS that overrides default behavior here. I wouldn't feel entirely comfortable fetching it from MediaWiki.org on the fly--but we can host the code within Gerrit. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugday today (16:30 - 20:30UTC) on Skin and page rendering issues
Hi, a quick reminder that today is a Wikimedia Bugday: Tuesday, April 02, 16:30-20:30UTC [1] in #wikimedia-office on Freenode IRC [2] This time we're in #wikimedia-office instead of #wikimedia-dev. Everyone is welcome to join, and no technical knowledge needed! It's an easy way to get involved in the community or to give something back. This even is part of a weekly QA activity [3], so we encourage you to triage throughout the week and record your activity on the bug day etherpad [4]. This information and more can be found here: https://www.mediawiki.org/wiki/Bug_management/Triage/20130402 For more information on Triaging in general, check out https://www.mediawiki.org/wiki/Bug_management/Triage Looking forward to seeing you there! andre [1] Timezone converter: http://www.timeanddate.com/worldclock/converter.html [2] See http://meta.wikimedia.org/wiki/IRC for more info on IRC chat [3] https://www.mediawiki.org/wiki/QA/Weekly_goals [4] http://etherpad.wmflabs.org/pad/p/BugTriage -- 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] Gerrit actively discourages discussion
For my own changes I have a workflow that's a little clunky, but works for me. I'll comment or mark done on every comment, so if I see the same number of drafts as comments, I know I've addressed them all. The workflow I have not found is a way to efficiently re-review other people's changes that I've previously reviewed. It takes a lot of time to properly review a big change, and I don't know an easy way to say Show me all my comments on previous patch sets so I can see if they have been addressed. Luke Welling On Tue, Apr 2, 2013 at 9:10 AM, Chad innocentkil...@gmail.com wrote: On Tue, Apr 2, 2013 at 9:03 AM, MZMcBride z...@mzmcbride.com wrote: Would it be possible to have Gerrit import a JavaScript page from MediaWiki.org (e.g., MediaWiki:Gerrit.js)? This might allow dedicated users to override some of the default behavior (such as the block-level comment auto-collapsing) or add new functionality (such as a reply link similar to Bugzilla's). There's functionality to write custom Javascript and inject it within Gerrit. So yes, we could easily have our own JS that overrides default behavior here. I wouldn't feel entirely comfortable fetching it from MediaWiki.org on the fly--but we can host the code within Gerrit. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mobile caching improvements are coming
Hi Max, On Mar 29, 2013, at 10:45 AM, Max Semenik maxsem.w...@gmail.com wrote: Hi, we at the mobile team are currently working on improving our current hit rate, publishing the half-implemented plan here for review: == Proposed strategy == * We don't vary pages on X-Device anymore. * Because we still need to give really ancient WAP phones WML output, we create a new header, X-WAP, with just two values, yes or not[1] * And we vary our output on X-WAP instead of X-Device[2] * Because we still need to serve device-specific CSS but can't use device name in page HTML, we create a single ResourceLoader module, mobile.device.detect, which outputs styles depending on X-Device.[2] This does not affect bits cache fragmentation because it simply changes the way the same data is varied, but not adds the new fragmentation factors. Bits hit rate currently is very high, by the way. Yes. It does add Vary processing on the bits caches for these requests though. But we can change that by including the X-Device header into the hash for cache lookups, if we want to. * And because we need X-Device, we will need to direct mobile load.php requests to the mobile site itself instead of bits. Not a problem because mobile domains are served by Varnish just like bits. * Since now we will be serving ResourceLoader to all devices, we will blacklist all the incompatible devices in the startup module to prevent them from choking on the loads of JS they can't handle (and even if they degrade gracefully, still no need to force them to download tens of kilobytes needlessly)[3] Good work! This should help a great deal. Your comments are highly appreciated! :) I've been pondering a bit about the two options for serving mobile ResourceLoader requests with Varnish: on the bits caches or on the mobile caches. I don't fully like either option to be honest. On one hand I'd like to keep mobile device detection off our currently very efficient bits caches, on the other hand I don't like the idea of mixing in the RL requests into the high churn of mobile request LRU cache eviction of the frontend caches. Unfortunately Varnish currently doesn't allow us to separate/specify cache backends for objects well. So let's go with Asher's suggestion indeed, and add the device detection to the bits servers. Let's keep it such that it'll always be easy to distinguish these requests, so we can easily decide to move these to another Varnish cluster at any point. -- Mark Bergsma m...@wikimedia.org Lead Operations Architect Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.21.0rc1 -- Help test 1.21 and update the announcement
On Sun, Mar 31, 2013 at 6:49 PM, Mark A. Hershberger m...@everybody.org wrote: I've just finished preparing the first release candidate for MediaWiki 1.21 and I'd like your help testing it before the final release. Please download the release candidate and test it. If you find any bugs please report them on Bugzilla[1] and make sure I am added as a CC so that we can fix any show-stoppers before the final release. Finally, if you could also look over https://www.mediawiki.org/wiki/MediaWiki_1.21, I'll be using an edited version of that to make the final announcement. If you spot problems or areas that could use clarification, your help in improving it would be appreciated. [1] https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWikicc=m...@everybody.orgversion=1.21-git Full release notes: https://www.mediawiki.org/wiki/Release_notes/1.21 Is the large read-only textbox on the final install screen normal or not? http://i.imgur.com/QP7cLna.png ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.21.0rc1 -- Help test 1.21 and update the announcement
On 04/02/2013 12:27 PM, OQ wrote: Is the large read-only textbox on the final install screen normal or not? Normal in that I saw it as well during my quick sanity check of the tarball, but I think it deserves a bug. Please file one: https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWikicc=m...@everybody.orgversion=1.21-git Thanks for testing! -- http://hexmode.com/ [We are] immortal ... because [we have] a soul, a spirit capable of compassion and sacrifice and endurance. -- William Faulker, Nobel Prize acceptance speech ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mobile caching improvements are coming
On 02.04.2013, 20:16 Mark wrote: I've been pondering a bit about the two options for serving mobile ResourceLoader requests with Varnish: on the bits caches or on the mobile caches. I don't fully like either option to be honest. On one hand I'd like to keep mobile device detection off our currently very efficient bits caches, on the other hand I don't like the idea of mixing in the RL requests into the high churn of mobile request LRU cache eviction of the frontend caches. Unfortunately Varnish currently doesn't allow us to separate/specify cache backends for objects well. So let's go with Asher's suggestion indeed, and add the device detection to the bits servers. Let's keep it such that it'll always be easy to distinguish these requests, so we can easily decide to move these to another Varnish cluster at any point. The puppet changes for this are at https://gerrit.wikimedia.org/r/#/c/56774/ Anything else needed? -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: New Beta release of Wikimedia Commons App!
Since I don't think anyone reads mobile-l. -- Forwarded message -- From: Yuvi Panda yuvipa...@gmail.com Date: Wed, Apr 3, 2013 at 12:53 AM Subject: New Beta release of Wikimedia Commons App! To: mobile-l mobil...@lists.wikimedia.org Hello! New beta release of commons app went out today! Features of v1.0 beta 6 include: ## v1.0 beta 6 - Add categorization - Add a 'Modifications Sync' framework for doing eventual-consistent page edits - More consistent designb between single and multiple upload - i18n updates You can now add categories to your uploads, both single and multiple uploads! They will be 'eventually consistent' - the categories aren't saved immediately as you hit the 'save' button but will be saved on next sync, whenever Android decides that is. We're getting closer to a full v1.0 release - user account creation and a bit more polish ought to do it. Bug reports welcome at https://bugzilla.wikimedia.org/enter_bug.cgi?product=Commons%20App (pick the Android component). Pull requests welcome at https://github.com/wikimedia/android-commons Thank you! -- Yuvi Panda T http://yuvi.in/blog -- Yuvi Panda T http://yuvi.in/blog ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.21.0rc1 -- Help test 1.21 and update the announcement
Slightly related here, https://gerrit.wikimedia.org/r/#/c/57067/ should be included in 1.21. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.21.0rc1 -- Help test 1.21 and update the announcement
On 04/02/2013 05:30 PM, Brad Jorsch wrote: Slightly related here, https://gerrit.wikimedia.org/r/#/c/57067/ should be included in 1.21. Very related. Thanks for pointing this out. https://gerrit.wikimedia.org/r/#/c/57198/ If anyone else is aware of similar bug fixes that should go into 1.21, please either notify me or submit them to REL1_21 -- http://hexmode.com/ [We are] immortal ... because [we have] a soul, a spirit capable of compassion and sacrifice and endurance. -- William Faulker, Nobel Prize acceptance speech ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit actively discourages discussion
Christian Aistleitner wrote: while I do not want to discourage discussion of those items on wikitech-l, I nevertheless filed them in bugzilla, so we can keep track of the issues / solutions. This is wonderful. Thank you for filing these bugs, Christian. I'll take a look at them now. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit actively discourages discussion
I feel very dirty having done this but I made a chrome extension that autoexpands all comments and adds a comment count next to unexpanded older patchsets. The code's horrible but it works - feel free to try it out: https://github.com/jdlrobson/gerrit-be-nice-to-me I suspect the best long term solution might be to rewrite the interface. The fact it is so ajaxay makes enhancements hard unless someone actually wants to get to know and work on the gerrit codebase themselves... On Tue, Apr 2, 2013 at 7:54 PM, MZMcBride z...@mzmcbride.com wrote: Christian Aistleitner wrote: while I do not want to discourage discussion of those items on wikitech-l, I nevertheless filed them in bugzilla, so we can keep track of the issues / solutions. This is wonderful. Thank you for filing these bugs, Christian. I'll take a look at them now. MZMcBride ___ 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] Gerrit actively discourages discussion
This is awesome!!! Thanks Jon :) And no, I didn't look at the code, too scared :) On Wed, Apr 3, 2013 at 1:14 AM, Jon Robson jdlrob...@gmail.com wrote: I feel very dirty having done this but I made a chrome extension that autoexpands all comments and adds a comment count next to unexpanded older patchsets. The code's horrible but it works - feel free to try it out: https://github.com/jdlrobson/gerrit-be-nice-to-me I suspect the best long term solution might be to rewrite the interface. The fact it is so ajaxay makes enhancements hard unless someone actually wants to get to know and work on the gerrit codebase themselves... On Tue, Apr 2, 2013 at 7:54 PM, MZMcBride z...@mzmcbride.com wrote: Christian Aistleitner wrote: while I do not want to discourage discussion of those items on wikitech-l, I nevertheless filed them in bugzilla, so we can keep track of the issues / solutions. This is wonderful. Thank you for filing these bugs, Christian. I'll take a look at them now. MZMcBride ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Taking out the garbage
Hi all, tl;dr: I've cleaned up the mediawiki/core repo, and performance for fetch/clone operations should be noticeably faster. So, due to some recent upgrades in Gerrit, we've now got GC support in JGit as a result. Gerrit supports this functionality, which will greatly reduce the size of our repositories on-disk. It also makes use of an improved bitmap algorithm for fetches clones, making them wayyy faster. I've now run this on mediawiki/ core, and the repo went from 3.0G down to ~620M on disk. You should now notice all read actions (over https ssh) to be way faster--a fresh clone should now only be limited by your bandwidth, not how fast Gerrit can serve the repo from disk. If you notice *any* problems with mediawiki/core, please let me know immediately. If everything looks good, we'll set this up as a cron to run weekly or something for all repositories. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
