This week on the planning call, I would like to discuss our policy and practices for long-lived branches.
A long-lived branch is one where:
1. It spans > 2 releases (more than a month), which triggers frequent rebasing.
2. Has multiple contributors.
3. May be using PRs as a way to coordinate changes to the branch itself.
In some cases, engineers are contributing to long-lived branches directly with commits. We have also had a couple scenarios where PRs are being used to track contributions into the branch itself. Since the PRs are going into a branch that is not master, they have had a different standard of review and acceptance applied. The longer the branch lives, the potentially harder it will be for that branch to get merged into master.
Another scenario is that we have had some PRs opened which challenges the design of the system - either alters the original design intent, affects the infrastructure, or alters the usability of the system. When these PRs are tied to specifications that were drafted and reviewed, the adoption path is clear. However, if the PRs both introduce the concept and provide an implementation, then it is harder to manage the PR as maintainers wrestle with deciding on whether the alteration is a good change and with the maintainability of the code.
I'd like to use the time on our call to capture any guidelines / rules / processes that should be added into our development workflow standards and wiki. Maintainers would be responsible for making sure all of our contributors are informed and then follow suit.
Tyler
Tyler Jewell // CEO // tyler@codenvy.com // 978.884.5355
