Impact on Infrastructure

Impact on Workflow

How are existing reviews going to be handled?

How will cutover be handled?

Pull requests (reviews in gerrit) are merge based. Scripting / tooling required to have the support for fast-forward merge requests for commits.
Gitflow provides better workflow management for the Git PR to the trunk and release branches
Better UI and search capability
Good collaboration with other community based open source software
Pull requests that are draft mode needs prefix "WIP" (Work in progress) and need tooling for filtering
Predefined events for Webhooks
Simple and easy to understand and onboard
Checkpoint pull request. This enables to "checkpoint" tasks as they succeed in a way which allows to see results as the pipeline proceeds.

Sometimes, a workflow policy might mandate a clean commit history without merge commits. In such cases, the fast-forward merge is the perfect candidate. With fast-forward merge requests, you can retain a linear Git history and a way to accept merge requests without creating merge commits.
Atomic/related changes in all one commit is necessary for context affinity, relativity and granularity to better manage the changes as a set function.
Submit the change set in the review as "draft" to provide better filtering, visibility and manageability
Pre-commit code review and comment on diffs
Rating for the reviews which makes visibility better than looking for comments, especially in an automated workflow
Better diff ability on the rebase and squash for the review thread, especially when a inline review comments were made to the original / subsequent review submissions.
Permission model by using tags on top of git set permission which provides CI admins control over the reviews. This helps with consistency and operations, from CI to release.
Better integration with issue tracking, workflow and automation via webhooks (jira, launchpad etc)
Better integration with Jenkins
Customizable webhooks using hooks plugins
No intuitive UI
Poor CLI consistency