Because unless the unit test suite has 100% line and branch coverage, and possibly various other metrics, all of which are unfeasible for any real-world sized code base, it could miss something. The first line should/must (if you care) be manual integration of the two change sets, conflicting, or not. That's why! :-p
What you're suggesting is a good thing, however what you said was false or at best misleading. Part of the issue I see is that people keep rebasing so that they can be sure their changes will merge without conflict. I don't see that as an issue, I see that as due diligence and a wise thing to do in a dynamic code base. On 20 March 2017 at 20:15, Stephen Connolly <stephen.alan.conno...@gmail.com > wrote: > On Mon 20 Mar 2017 at 00:44, Fred Cooke <fred.co...@gmail.com> wrote: > > > 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. > > > > How is Jenkins checking that the branch merges cleanly rubbish? > > GitHub does that all the time for PRs > > Part of the issue I see is that people keep rebasing so that they can be > sure their changes will merge without conflict. > > If Jenkins has tested that the changes will merge without conflict, no need > to rebase and push the rebase just to get the test status updated... > because it is updated. > > We cannot have Jenkins *push* the merge anywhere.... it would just be > verifying that the merge is without conflict and "trivial"... and running > the tests on the result > > > > > On 20 March 2017 at 10:20, Stephen Connolly < > > stephen.alan.conno...@gmail.com > > > wrote: > > > > > 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 > > > > > > -- > Sent from my phone >
