Google takes the pain out of code reviews, with 97% dev satisfaction

Re:Google takes the pain out of code reviews, with 97% dev s... by jsight on Monday December 04, 2023 @01:03PM (#38520647)

Yes, it is pretty common to require re-review if it is changed again. But approval with comments shifts control back to the submitter. They then have choices:

- Modify it and accept that this will trigger re-review

- Merge as-is... maybe they don't even agree with the nit

- Merge as-is and followup with a new MR under the same JIRA. This sometimes makes sense if it gets them into an important preprod environment, but they are really still working on the issue.

- Merge as-is and follow up with a JIRA on the backlog. Maybe they realized that the "nit" is really a bigger issue and should be addressed separately.

Regardless, there's value in not blocking the merge for non-functional issues.

[ Parent | on HN ]

Re:Google takes the pain out of code reviews, with 97% dev s... by lazyasciiart on Monday December 04, 2023 @02:48PM (#38522178)

I got a merge blocked last week with the comment 'I think this work is more related to "TFS X: prepare for Y" than it is "TFS Y".' (I eventually realized they wanted me to change the commit message). I hate this fucking team.

[ Parent | on HN ]