Just two cents from a long-time list lurker: First, congrats on all the work done so far! Monumental effort, and a well-deserved congratulations to everyone involved.
As a Release Manager, > > I cannot tell which branches on the CI server are targeted for the release > and which are "future work" > IMHO, this is the job of the issue tracking system. It is the authority on what work is targeted for which release. It is also the place where the impact or nature of the work is tracked (bug, feature enhancement, etc.), and whom is doing the work. So I'm not sure that the CI server is the place where you would go *first* to see what branches are targeting which release. Unfortunately, that process would first require searching the issue tracking system for issues targeting a certain release, and then each issue would have a link to the branch. I see how a convention for naming branches could be helpful, but that seems a bit complex and requires everyone to comply with multiple rules (rules for the metadata required for an issue, which will have a link to the branch, and then rules for how a branch should be named). I cannot tell who is responsible for which branches in order to know who to > ask w.r.t. their status > Right; I think that's the responsibility of the issue tracker. It knows what issues are being worked on for a release, and the release manager can use the issue tracker to see what is in-progress, and directly ask the developer who owns the issue. No need to even look at the CI system. But, each issue should have a link to the branch being used for the work, which could be used by the release manager if needed. As a PMC member tasked with reviewing commits > > I cannot keep track of all the many commits and rebases > *If* the process is review then commit, a pull request would be opened by the owner of a branch against "master" (or whatever the target branch is). That is how a PMC member would know it is time to review a series of commits. The owner of the branch would be responsible for insuring that it can apply cleanly to the target branch at any time. For example, the owner of the branch opens a PR. It must apply cleanly to the target branch at the time the PR is opened (i.e. the branch must be based on the tip of the target). If, prior to merging the PR, the target branch progresses, the owner of the branch would need to rebase the branch and update the PR. To me this seems like a clean separation of responsibilities. The owner of a branch indicates that their work is ready for merging by requesting a PR. It is the owner's responsibility to keep the PR current with respect to the target branch. The PMC member or release manager is notified of the PR, and their responsibility is to perform a review, and either accept the merge request or ask for more changes (asking for more changes could mean: "please rebase this against the current tip of the target branch"). As PRs are accepted and merged into their target branches, the corresponding issues in the tracking system are updated with this information, and closed. Having PRs that apply cleanly to the target branch also invites other developers who may not bear official responsibility, to attempt to build the branch and review the PR as well. That is to say, cleanly applying PRs may have more eyes on them during the review process. Just my thoughts! > > Proposal > ======== > > 1. We should use a naming scheme for all branches. I am suggesting > owner/targetBranch/mng-XXXX - this gives me the information about who owns > the branch and where the branch is targeted for. > > 2. We should have the Jenkinsfile build not just the head commit but the > head commit merged to the target branch for any branch following the naming > scheme. We get the target branch from the naming scheme and by having the > build verify that the branch can be merged without conflict onto the target > branch we remove the need for constant rebases > > 3. We merge branches with an explicit merge commit and stop using > fast-forward merging only. Again this makes it easier to review and allows > the noisy branches to be quiet when looked at from the PoV of master > > This will not solve all the issues, but it would solve the pain points I > have currently. > > Now if others have a different PoV or a counter-proposal, please speak up! >
