fyi, as we'll probably continue to use the same codereview tool as the rest of chromium projects
---------- Forwarded message --------- From: Andrew Bonventre <andyb...@chromium.org> Date: Di., 12. Juli 2016, 23:24 Subject: [blink-dev] [ANN] Moving from Rietveld to Gerrit To: Chromium-dev <chromium-...@chromium.org>, blink-dev < blink-...@chromium.org>, <tand...@chromium.org> *Summary* The Chromium project is moving away from Rietveld to a revamped version of Gerrit for our main Code Review tool. *When?* The conservative estimate is Q4 of 2016. There are already some Chromium teams dogfooding the new Polymer-based UI (called PolyGerrit) and we are using their feedback to ensure that there is both a smooth transition and developer needs are met. This process will continue as we onboard more people. *Why?* We (Chromium) are the only customers of Rietveld (codereview.chromium.org and its internal counterpart) and maintenance of the tool has been delegated to a single person. The codebase has become a liability over the years and speed has become a major issue. Gerrit is a fast, secure, and fully-featured code review tool built as a successor to Rietveld. It is already used by some Chrome subteams along with the Android, Go, and Bazel teams (as well as many others both inside and outside Google). It is also a fully staffed project with heavy investment from Google. This also means full-time UX support. Its front-end is being re-written using Polymer, a standards-based library that allows us to take advantage of Web Components. This UI is the one that Chromium will be transitioning to (though you are welcome to use the old UI if you like). *FAQ* *Can I see current progress on PolyGerrit?* Yes. Download this extension <https://chrome.google.com/webstore/detail/gerrit-ui-switcher/fdjpjnlhaohkkbjnglcfehbmcmpojklf> and then visit https://chromium-review.googlesource.com. You can then toggle between the two UIs. *How can I start dogfooding it now?* We still have plenty to do on the infrastructure side of things before many teams can move over. If you have a sub-project you think may qualify for early migration, email me and +Andrii Shyshkalov <tand...@chromium.org>. *How can I follow progress?* All bugs related to the migration have the label Proj-Gerrit-Migration <https://bugs.chromium.org/p/chromium/issues/list?q=label:Proj-Gerrit-Migration>. Additionally, on the Gerrit project, there is a list of Chromium-specific bugs <https://bugs.chromium.org/p/chromium/issues/list?q=label:Proj-Gerrit-Migration> . *What will happen to Rietveld?* Rietveld will be put in read-only mode to preserve change history. Potential migration of changes to Gerrit will be considered after the switch. A unified CL search interface is being strongly considered. *Why not continue to just maintain Rietveld?* The Chromium infra team is stretched far too thin as it is and keeping the status quo of having one or no owner for the Rietveld codebase isn’t tenable given its fragility. The bus factor is just too low. That coupled with the duplication of effort across the Gerrit and Rietveld projects, it doesn’t make strategic sense. We would rather focus on more important work that will bring immediate benefit to Chromium developers. *Why don’t you move the current Rietveld v2 UI on top of Gerrit?* The current Rietveld v2 UI is written in Polymer 0.5, which is no longer supported by the Polymer team. There is a non-trivial amount of work that will go into porting it to 1.0. In addition, there are certain workflows within Gerrit that must be supported, so blindly porting the new Rietveld UI could potentially omit those workflows and cause confusion. *Will this change my current command-line development workflow?* No. git cl will support a Rietveld-style workflow with Gerrit transparently. You can follow this tracking bug to be informed on feature parity with git cl on Rietveld. *I heard I can’t “LGTM with nits.” This is a huge productivity loss if I’m working with people across timezones. Will I have to approve again if the author uploads another patchset?* No. Being able to submit a commit that doesn't exactly match the one that got approved is a per-project configuration option — you can choose in the config whether approvals are “sticky” or only per-patchset. *Are you going to go inside a hole for six months, return with a new tool, and then force everyone to use it?* No. Developer feedback (both from Chrome devs and current Gerrit users) will be crucial for the UI rewrite to be a success. We will be as transparent as possible with progress and will establish a feedback loop very early on. This isn’t about just alleviating maintenance burden, but making a tool that is crucial to everyone’s workflow better. If you have any questions or need clarification, please don’t hesitate to reach out. Andy -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
