+1 to the whole analysis on issue tracking vs scm

one addition: currently, our PR process is "asking for a second": IMHO, it 



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

Reply via email to