Pull Request Alternative Design Doc

The following is a Design Doc for an idealized alternative to what is currently the pull request work flow.

The Problem

The feature branch/pull request process is fundamentally broken a bunch of different ways. This can be improved significantly with a Patch Stack based workflow and tooling. But this is still far from ideal as when you have dependent patches you can't open a review for the higher level patch until the dependent patch is integrated into mainline. A stacked branch approach can elevate this but introduces other problems. Like, having to manage branch names up front as well as manage the DAG (directed acyclic graph) of the relationships between the branches. Also, it requires a completely different service that companies have to pay for to extend the peer review process, see Graphite.

Idealized Goals

• open patch review requests as soon as completed, even if they are patches that depend on another patch that has not been integrated into mainline yet.
• open patch review requests for a patch series communicating the dependence and order of dependence.
• don't require an additional service
• promote better reviews by actually having people use their own tools to review
• support reviewing commits after they are integrated into mainline as well as before they are integrated into mainline

The Thinking

The initial high level thought is, that if we were to use git format-patch or similar to facilitate the review process. Then the review would be free floating, or independent, even if it actually depended on another patch.

This can could be seen as a drawback. But in reality it is a benefit as it effectively lifts the requirement of that dependency from the point of requesting the review and moves it to the application of the patches.

This would allow the developer who wrote the patches to effectively request review for each of them independently even if they had dependence of another patch that has yet to be integrated into mainline.

This might not eliminate the concept of a patch series all together. But it gives you flexibility and optionality in terms of workflow.

pr.pico.sh is the closest thing to this that I have come across. Though, it is a separate service that you would need to host.