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

Reply via email to