maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Cooke <fred.co...@gmail.com>
Subject Re: [DISCUSS] How to work with branches
Date Mon, 20 Mar 2017 07:38:01 GMT
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.connolly@gmail.com
> wrote:

> On Mon 20 Mar 2017 at 00:44, Fred Cooke <fred.cooke@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.connolly@gmail.com
> > > wrote:
> >
> > > On Sun 19 Mar 2017 at 20:05, Fred Cooke <fred.cooke@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.connolly@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message