Workflow with stacked pull requests

[elBoberido]

The current workflow with a PR from a personal repository has a few drawbacks, especially with bigger changes.

Let's assume one introduces a new feature. To get a feeling how the API of the new feature works, the feature is developed in parallel with an example and also integrated into the code base. This leads to big PRs which are hard to review and increases the probability for bugs to slip in. An alternative would be to have multiple smaller PRs but when the PR comes from a different repo, this doesn't make the life of the reviewer much easier. The first PR will be small but all subsequent PR will have the changes from the previous ones which are not yet merged. This would be different when the PR comes from the same repo since once could have a chain of PRs where one PR targets the branch of the previous PR, also known as stacked pull requests. The life for the reviewer is much easier since there are multiple PR, each with only the relevant changes. There is no context switch from one file to the next one because all files are either the new feature or the example or the integration. So one could split a PR into multiple PRs and the reviewer would still not wonder whether some files are from the previous PR.

Here are some blog posts describing this in greater detail
https://medium.com/inside-bukalapak/smaller-faster-code-review-with-stacked-merge-request-1dc130705bc1
https://blog.logrocket.com/using-stacked-pull-requests-in-github/

There would be slightly more work for the developer but this would pay off during review.

To accomplish this, we would need to work on branches on eclipse-iceoryx/iceoryx. AFAIK, this is only possible for committer but this wouldn't be a big problem from my point of view since regular contributors would become committer over time and irregular contributors most probably don't have big PRs.

The workflow would basically be as following:

• one branch with feature + tests
• one branch with the integration
  • based on the feature branch
  • needs to be rebased on the feature branch when there is further development on that branch
• one branch with the example
  • same workflow like with the integration branch

What do you think?

@budrus @FerdinandSpitzschnueffler @dkroenke @MatthiasKillat @mossmaurice @elfenpiff

[budrus]

@elBoberido sounds good. Shall we discuss this in the next developer meeting?

[elBoberido]

Sure