How are branches noisy? Promiscuous automated emails or some such? Surely you don't need to look at all branches unless you've been asked to pre-review something prior to fast-forward? Just the ones you're interested in?
Naming scheme sounds sensible, however unless everyone is constantly rebasing (or making a mess with merge) there's a solid chance they won't merge cleanly (which is a human operation). Also, unless you're talking about maven itself with multiple supported versions, there should be exactly one target branch for most stuff, so I'd say reorder your pattern to reduce base-level "noise", eg target/owner/ticket-purpose On 20 March 2017 at 06:34, Stephen Connolly <[email protected] > wrote: > Unlike the other discuss threads, I think I have some extra context that > means I am going to start from my proposal... or rather my requirements and > then proposal to solve those requirements. > > Requirements > =========== > > As a Release Manager, > > I cannot tell which branches on the CI server are targeted for the release > and which are "future work" > > I cannot tell who is responsible for which branches in order to know who to > ask w.r.t. their status > > As a PMC member tasked with reviewing commits > > I cannot keep track of all the many commits and rebases > > 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! >
