Sounds like the solution is for people to use a different remote that you don't feel personally responsible for checking every commit in. And to fix the email system.
Split emails for commits on master to everyone and a new list for other branches. As for Jenkins validating a merge, that's rubbish. A merge, or a rebase, is a human operation, even when the tool can do it "cleanly"/automatically. To ignore this is to introduce subtle issues and breakages. On 20 March 2017 at 10:20, Stephen Connolly <[email protected] > wrote: > On Sun 19 Mar 2017 at 20:05, Fred Cooke <[email protected]> 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 [email protected] 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 < > > [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! > > > > > > -- > Sent from my phone >
