+1 to the whole analysis on issue tracking vs scm one addition: currently, our PR process is "asking for a second": IMHO, it works
Regards, Hervé Le dimanche 19 mars 2017, 22:27:20 CET Elliot Metsger a écrit : > 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! --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
