On Sun 19 Mar 2017 at 23:38, Christian Schulte <[email protected]> wrote:

> Am 03/19/17 um 18:34 schrieb Stephen Connolly:
> > 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.
>
> s/targetBranch/targetVersion/g
>

If it isn't targetBranch then we can only merge to master...

If that's what we want then:

1. We cannot have people pushing branches for fixes that cannot land on
master now (perhaps keep future work on GitHub)

2. No point in including a target branch or version.... just owner/mng-XXXX


> We currently have 3.5.0-SNAPSHOT on master. There is no way to create a
> branch for 3.5.1-SNAPSHOT today using that naming scheme. Today, master
> is at 3.5.0-SNAPSHOT, in one year master is at 3.6.0-SNAPSHOT. Creating
> a branch like schulte/master/MNG-6135 today, does not indicate the
> target version. The branch should be named schulte/3.6.0/MNG-6135. Not
> sure the name really is needed. Finding out about the author or
> committer is easy looking at the latest commits.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
> --
Sent from my phone

Reply via email to