On Sun 19 Mar 2017 at 20:05, Fred Cooke <fred.co...@gmail.com> wrote:
> How are branches noisy? Promiscuous automated emails or some such? PMC (and committers too, but the buck stops at the PMC) are supposed to monitor the commits@m.a.o mailing list. Every time a branch is rebased... boom all the commits are emailed *again* > > 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? Need to check for Apache license issues and other ill-defined criteria > > 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). This is why Jenkins will validate the merge cleanly so that the human has an easy merge > > 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 Perhaps, though then a lot of branches will start with "master/" Otoh it does make it easier to find all targeting master... > On 20 March 2017 at 06:34, Stephen Connolly < > stephen.alan.conno...@gmail.com > > 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! > > > -- Sent from my phone
