[Announcement] Gerrit is now open for business!

9 views
Skip to first unread message

Aaron Gable

unread,
May 10, 2017, 5:23:19 PM5/10/17
to Chromium-dev, blink-dev

Hi Chromium and Blink devs,


tl;dr: Use gerrit in chromium/src with git cl upload --gerrit! File bugs here! Let us know what you think!


As we've announced before, Chromium is in the process of changing over from using Rietveld for code review to using Gerrit. As of today, Gerrit is ready for the full force of your usage and testing. We'd like to invite all Chromium contributors to dogfood Gerrit for your code reviews.


Here are some things we've improved thanks to early dogfood feedback:

We also have some exciting stuff coming up soon:

  • Themes for different hosts (e.g. external and internal), so you can tell them apart at a glance


Whenever you're uploading a code review against chromium/src.git, please consider uploading the change to Gerrit instead of Rietveld.


To upload a change to Gerrit instead of Rietveld, just run

   git cl upload --gerrit

when uploading the change for the first time. Additional patchsets after the first will automatically upload to the same review. If you would like all of your Chromium reviews to go to Gerrit without having to pass the flag, simply run

   git config --local gerrit.host true

in your local repository checkout. If you have done the above and need a temporary escape hatch, you can upload with git cl upload --rietveld, and please file a bug or send feedback about why you needed to switch back.


When using Gerrit, you should get the new UI (PolyGerrit) by default. If you don't (because you have used Gerrit in the past and expressed a UI preference then), please click the "New UI" link in the footer or follow this link to use the new one instead.


This FAQ should hopefully address any questions you might have. The settings page also has a lot of things you can tweak if they aren't to your liking. If you run into any issues interacting with your CLs from the command line or landing them via the commit queue, please file a bug here. If you run into any issues using the PolyGerrit web application, please file a bug at here.


We really value your feedback on Gerrit and want to hear about your experience using it so that we can continue improving it and make this transition as smooth as possible. We look forward to hearing from you!


Thanks,

Aaron


P.S. Yes, this does mean that we'll be using both Gerrit and Rietveld side-by-side for the near future. The more helpful the feedback we receive is, the quicker we'll be able to switch away from Rietveld entirely.

--
You received this message because you are subscribed to the Google Groups "infra-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-announc...@chromium.org.
To post to this group, send email to infra-a...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-announce/CAH58R2fD8yys%2BJZVL9ZZnCvMU9QcAq5mLAfsMQpAcyqLTYd8AQ%40mail.gmail.com.

Paweł Hajdan, Jr.

unread,
May 12, 2017, 9:34:50 AM5/12/17
to Aaron Gable, infr...@chromium.org, Andrew Grieve, Nico Weber, Primiano Tucci, Chromium-dev, blink-dev
+infra-dev (IMO useful to keep in the loop)

On Thu, May 11, 2017 at 9:22 PM, Aaron Gable <aga...@chromium.org> wrote:
On Thu, May 11, 2017 at 7:12 AM Andrew Grieve <agr...@chromium.org> wrote:
1. If you try to reuse the same upload message as a previous patch (I often just type "rebase"), upload fails with a 500 error.

That's very odd, and not a behavior I've been able to reproduce (e.g. both patchsets here have the exact same title). Please file a bug here with reproduction steps.

Intermittent bugs might be hard to catch/debug this way.

Do we have way to inspect the server-side logs once a user reports an error like this? Say they give us a CL ID, and then we just look up any HTTP 500s, and make sure any relevant details get included in the logs.

This technique proved very powerful when eradicating issues with CQ, both the python daemon itself, and any integration issues in related components.
 
2. Sometimes even with a unique message, it fails, but works upon retry. E.g.:
To https://chromium.googlesource.com/chromium/src.git
 ! [remote rejected]           ac39616cdd36d2db4fb5b3dcc7551e1fb1424891 -> refs/for/refs/heads/master%m=rebase2,notify=NONE (internal server error: Error inserting change/patchset)

But another run of "git cl upload" succeeded. This has happened to me a few times this week.

Yes, we're aware of this. There have been two minor gerrit outages in the past couple weeks which led to increased levels of 500s on write operations, i.e. failed pushes.

We may already have it, but just checking: do we have automatic exponential retry for this in git-cl?

I found that for many workflows, it's nice to run a fire-and-forget command: even if it's slow, I can switch to another terminal or email, and do something useful without need to manually monitor it.
 
3. Uploads are not as snappy as with Rietveld. I'm finding they take between 1 and 2 minutes to complete.

Woah, 1 to 2 minutes is unacceptable. I've never seen that myself, but we have received at least one other complaint about slowness. Can you fill in on that bug some details? In particular, is it slow for certain kinds of patchsets (e.g. ones with a very large diff, or ones where your local branch has a lot of commits on it)? At what point during the upload is it slow (e.g. after printing the summary of the diff it will upload, or during Processing Changes, or some other time)?

Also pushing a little bit: what's out ability to instrument things here, both server side and in git-cl?

The more we info we can get ourselves as opposed to requiring our users to repro intermittent issues, the faster we can fix issues like this. I'm speaking from experience solving intermittent issues in other systems.

Hopefully these ideas are useful, and you may have considered them. I was wondering if you'd consider them helpful, so that we can make the Chromium Gerrit launch successful. Looks like it's on the right track - it's great to see responsiveness to issues raised in this thread.

Thanks!

Paweł
 
4. Despite these minor issues, I've been overall quite happy with it!

Yay!
 


On Thu, May 11, 2017 at 9:45 AM, Nico Weber <tha...@chromium.org> wrote:
On Thu, May 11, 2017 at 9:43 AM, Primiano Tucci <prim...@chromium.org> wrote:
Excited to see progress on this!
I just have one question: does this mean that whether a CL comes from gerrit depends purely on the choice of the author now?
If so, does it mean that, as a reviewer, I have to watch now both codereview systems?

I think this has been true for a while already (people could opt in to gerrit before – at least I've been getting gerrit reviews from dcheng for chromium things for a while).

Yes, as noted in the postscript of the PSA, this does mean that we'll be using both systems side-by-side for a little while. (And as Nico points out, we already have been, although at a smaller scale.) That's why we need feedback from y'all to be as helpful as possible, and we need to act on it as fast as possible, so that we can get into a Gerrit-only state quickly and smoothly.

Thanks again, everybody!
Aaron
 
 

To unsubscribe from this group and stop receiving emails from it, send an email to infra-announce+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.
To post to this group, send email to infr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAH58R2fD8yys%2BJZVL9ZZnCvMU9QcAq5mLAfsMQpAcyqLTYd8AQ%40mail.gmail.com.



Reply all
Reply to author
Forward
0 new messages