Re: [DISCUSS] How to work with branches

[Hervé BOUTEMY]

+1 to the whole analysis on issue tracking vs scm

one addition: currently, our PR process is "asking for a second": IMHO, it 
works

Regards,

Hervé

Le dimanche 19 mars 2017, 22:27:20 CET Elliot Metsger a écrit :
> Just two cents from a long-time list lurker:
> 
> First, congrats on all the work done so far!  Monumental effort, and a
> well-deserved congratulations to everyone involved.
> 
> As a Release Manager,
> 
> > I cannot tell which branches on the CI server are targeted for the release
> > and which are "future work"
> 
> IMHO, this is the job of the issue tracking system.  It is the authority on
> what work is targeted for which release.  It is also the place where the
> impact or nature of the work is tracked (bug, feature enhancement, etc.),
> and whom is doing the work.  So I'm not sure that the CI server is the
> place where you would go *first* to see what branches are targeting which
> release.  Unfortunately, that process would first require searching the
> issue tracking system for issues targeting a certain release, and then each
> issue would have a link to the branch.
> 
> I see how a convention for naming branches could be helpful, but that seems
> a bit complex and requires everyone to comply with multiple rules (rules
> for the metadata required for an issue, which will have a link to the
> branch, and then rules for how a branch should be named).
> 
> I cannot tell who is responsible for which branches in order to know who to
> 
> > ask w.r.t. their status
> 
> Right; I think that's the responsibility of the issue tracker.  It knows
> what issues are being worked on for a release, and the release manager can
> use the issue tracker to see what is in-progress, and directly ask the
> developer who owns the issue.  No need to even look at the CI system.  But,
> each issue should have a link to the branch being used for the work, which
> could be used by the release manager if needed.
> 
> As a PMC member tasked with reviewing commits
> 
> > I cannot keep track of all the many commits and rebases
> 
> *If* the process is review then commit, a pull request would be opened by
> the owner of a branch against "master" (or whatever the target branch is).
> That is how a PMC member would know it is time to review a series of
> commits.  The owner of the branch would be responsible for insuring that it
> can apply cleanly to the target branch at any time.  For example, the owner
> of the branch opens a PR.  It must apply cleanly to the target branch at
> the time the PR is opened (i.e. the branch must be based on the tip of the
> target).  If, prior to merging the PR, the target branch progresses, the
> owner of the branch would need to rebase the branch and update the PR.
> 
> To me this seems like a clean separation of responsibilities.  The owner of
> a branch indicates that their work is ready for merging by requesting a
> PR.  It is the owner's responsibility to keep the PR current with respect
> to the target branch.  The PMC member or release manager is notified of the
> PR, and their responsibility is to perform a review, and either accept the
> merge request or ask for more changes (asking for more changes could mean:
> "please rebase this against the current tip of the target branch").
> 
> As PRs are accepted and merged into their target branches, the
> corresponding issues in the tracking system are updated with this
> information, and closed.
> 
> Having PRs that apply cleanly to the target branch also invites other
> developers who may not bear official responsibility, to attempt to build
> the branch and review the PR as well.  That is to say, cleanly applying PRs
> may have more eyes on them during the review process.
> 
> Just my thoughts!
> 
> > Proposal
> > 
> > 
> > 1. We should use a naming scheme for all branches. I am suggesting
> > owner/targetBranch/mng- - 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!



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] How to work with branches

[Hervé BOUTEMY]

IMHO, we don't have sufficient *team focus* on one version: how could we have 
focus on multiple versions at the same time?

working on creating a scheme to let people work without the others on another 
objective (which is supposed to be "the next one") is a recipe for split 
developer efforts

Regards,

Hervé

Le lundi 20 mars 2017, 00:38:26 CET Christian Schulte a écrit :
> 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- - this gives me the information about who owns
> > the branch and where the branch is targeted for.
> 
> s/targetBranch/targetVersion/g
> 
> 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,



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] How to work with branches

[Fred Cooke]

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  wrote:

> On Mon 20 Mar 2017 at 00:44, Fred Cooke  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  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- - 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 

Re: [DISCUSS] How to work with branches

[Karl Heinz Marbaise]

Hi,

On 19/03/17 18:34, Stephen Connolly 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"


This question can simply being answered by using JIRA and see the 
roadmap...there you can see all the issues intended for that particular 
release...


If someone needs some special attention for a particular issue this can 
be done via the mailing listOr if the RM is unsure about the given 
state in JIRA just ask on the mailing list...






I cannot tell who is responsible for which branches in order to know who to
ask w.r.t. their status


I need to repeat this. This is documented in JIRA (assignee)...

Both the status of the branch that's what the issue status is intended 
for...Is it already closed/resolved ?...


It might be usefull to make a separation between closed/resolved for 
this purpose?


Maybe this could be improved to add an appriprate label to JIRA issue 
(something like ready-for-integration)??





As a PMC member tasked with reviewing commits

I cannot keep track of all the many commits and rebases


It is the responsibility of the appropriate owner of the branch 
(assignee) in JIRA...and not the release manager...(from my point of view).


Based on each commit message I get this gives me the opportunity to 
review a commit..


The problem at the moment that the rebased will produce a large number 
of emails.




Proposal


1. We should use a naming scheme for all branches. I am suggesting
owner/targetBranch/mng- - this gives me the information about who owns
the branch and where the branch is targeted for.


This means from my point of view duplicating the information which is 
already maintained in JIRA...





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


The rebase part has the advantage that you can bring your code in sync 
with Master and in the end put the whole change into a single commit 
which is a very clean way.


Apart from that if you like to merge this change to an other branch a 
single commit can easily being cherry-picked to an other branch..using 
merge commits that is not that easy and a horror to follow such kind of 
history...





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 produce a large number of merge commits which makes it hard to 
read the history. Just having a single commit (cherry-picked) which 
contains the whole implementation of a ticket/feature is much more cleaner.


So in the end the history will contain informations like this:

"Merge branch MNG-5634"...

and the commits contain:

"[MNG-5634] ..."

So the information about the branch MNG-5634 is useless cause the branch 
does not exist anymore. The information MNG-5634 is important part to 
make a relationship to jira...



A fast forward merge can also be done automatically with Jenkins...This 
can be done fully automatically based on a schema or triggered by a 
person manually...






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!




Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] How to work with branches

[Stephen Connolly]

On Mon 20 Mar 2017 at 00:44, Fred Cooke  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  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- - 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

Re: [DISCUSS] How to work with branches

[Elliot Metsger]

On Sun, Mar 19, 2017 at 6:56 PM, Fred Cooke  wrote:

> No need to cherry-pick, that should be a rare operation.
>
> Clean up the branch and prepare it for a fast forward with high quality
> commits, then just push it when it's ready and passes scrutiny and tests.
>

I agree, cherry picking is _not_ a normal operation.  There are plusses and
minuses to different merge strategies, but I don't really consider cherry
picking to be one of them.

As an aside, I'm not sure if this would be too much for Maven, but check
out git-flow [0], which provides conventions and rationale around git
branch management vis-a-vis "hotfixes", "release branches", "feature
branches" etc.  Whilst adopting the whole of git-flow may be more complex
than this project needs, it does offer a clear rationale and definition for
different kinds of branches, and it may provide some ideas as the Maven
developers investigate their own solutions.

[0] https://datasift.github.io/gitflow/IntroducingGitFlow.html



+1 on ugly masters. Last time I looked at the docker project the displayed
> history showed 15 or so merge commits and NO content commits. Useless.
>
> On 20 March 2017 at 11:46, Hervé BOUTEMY  wrote:
>
> > until now, target version was managed through Jira issue: I'm not
> convinced
> > putting the info in an additional place like branch name will help keep
> > info
> > in sync
> >
> > For the merge idea, the "target branch" concept seems too much for me: if
> > the
> > branch was automatically locally rebased on master, this would be simpler
> > and
> > sufficient IMHO
> >
> > And I completely dislike merge commits and remaining branches in master:
> > commits should be cherry picked and merge commit totally avoided IMHO.
> > Merge commits (and complex history retained from this practice) is a big
> > pain
> > point to me to have a clear master history
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 19 mars 2017, 17:34:21 CET Stephen Connolly a écrit :
> > > 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- - 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!
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [DISCUSS] How to work with branches

[Elliot Metsger]

Just two cents from a long-time list lurker:

First, congrats on all the work done so far!  Monumental effort, and a
well-deserved congratulations to everyone involved.

As a Release Manager,
>
> I cannot tell which branches on the CI server are targeted for the release
> and which are "future work"
>


IMHO, this is the job of the issue tracking system.  It is the authority on
what work is targeted for which release.  It is also the place where the
impact or nature of the work is tracked (bug, feature enhancement, etc.),
and whom is doing the work.  So I'm not sure that the CI server is the
place where you would go *first* to see what branches are targeting which
release.  Unfortunately, that process would first require searching the
issue tracking system for issues targeting a certain release, and then each
issue would have a link to the branch.

I see how a convention for naming branches could be helpful, but that seems
a bit complex and requires everyone to comply with multiple rules (rules
for the metadata required for an issue, which will have a link to the
branch, and then rules for how a branch should be named).

I cannot tell who is responsible for which branches in order to know who to
> ask w.r.t. their status
>

Right; I think that's the responsibility of the issue tracker.  It knows
what issues are being worked on for a release, and the release manager can
use the issue tracker to see what is in-progress, and directly ask the
developer who owns the issue.  No need to even look at the CI system.  But,
each issue should have a link to the branch being used for the work, which
could be used by the release manager if needed.

As a PMC member tasked with reviewing commits
>
> I cannot keep track of all the many commits and rebases
>

*If* the process is review then commit, a pull request would be opened by
the owner of a branch against "master" (or whatever the target branch is).
That is how a PMC member would know it is time to review a series of
commits.  The owner of the branch would be responsible for insuring that it
can apply cleanly to the target branch at any time.  For example, the owner
of the branch opens a PR.  It must apply cleanly to the target branch at
the time the PR is opened (i.e. the branch must be based on the tip of the
target).  If, prior to merging the PR, the target branch progresses, the
owner of the branch would need to rebase the branch and update the PR.

To me this seems like a clean separation of responsibilities.  The owner of
a branch indicates that their work is ready for merging by requesting a
PR.  It is the owner's responsibility to keep the PR current with respect
to the target branch.  The PMC member or release manager is notified of the
PR, and their responsibility is to perform a review, and either accept the
merge request or ask for more changes (asking for more changes could mean:
"please rebase this against the current tip of the target branch").

As PRs are accepted and merged into their target branches, the
corresponding issues in the tracking system are updated with this
information, and closed.

Having PRs that apply cleanly to the target branch also invites other
developers who may not bear official responsibility, to attempt to build
the branch and review the PR as well.  That is to say, cleanly applying PRs
may have more eyes on them during the review process.

Just my thoughts!


>
> Proposal
> 
>
> 1. We should use a naming scheme for all branches. I am suggesting
> owner/targetBranch/mng- - 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!
>

Re: [DISCUSS] How to work with branches

[Fred Cooke]

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  wrote:

> On Sun 19 Mar 2017 at 20:05, Fred Cooke  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- - 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
>

Re: [DISCUSS] How to work with branches

[Stephen Connolly]

On Sun 19 Mar 2017 at 22:56, Fred Cooke  wrote:

> No need to cherry-pick, that should be a rare operation.
>
> Clean up the branch and prepare it for a fast forward with high quality
> commits, then just push it when it's ready and passes scrutiny and tests.
>
> +1 on ugly masters. Last time I looked at the docker project the displayed
> history showed 15 or so merge commits and NO content commits. Useless.


All depends on POV

I happen to prefer merge commits - but I would say that having gotten
correct --first-parent support added to more of the git CLI

Having looked at how people abuse git, I actually think we'd have a cleaner
history if we required merge commits and banned fast-forward commits.
Certainly keeps code review simpler..,

OTOH perhaps this is just a problem that can be solved by INFRA if we get
them to only notify for tags and protected branches


>
> On 20 March 2017 at 11:46, Hervé BOUTEMY  wrote:
>
> > until now, target version was managed through Jira issue: I'm not
> convinced
> > putting the info in an additional place like branch name will help keep
> > info
> > in sync
> >
> > For the merge idea, the "target branch" concept seems too much for me: if
> > the
> > branch was automatically locally rebased on master, this would be simpler
> > and
> > sufficient IMHO
> >
> > And I completely dislike merge commits and remaining branches in master:
> > commits should be cherry picked and merge commit totally avoided IMHO.
> > Merge commits (and complex history retained from this practice) is a big
> > pain
> > point to me to have a clear master history
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 19 mars 2017, 17:34:21 CET Stephen Connolly a écrit :
> > > 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- - 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!
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
-- 
Sent from my phone

Re: [DISCUSS] How to work with branches

[Stephen Connolly]

On Sun 19 Mar 2017 at 23:38, Christian Schulte  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- - 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-


> 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: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: [DISCUSS] How to work with branches

[Christian Schulte]

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- - this gives me the information about who owns
> the branch and where the branch is targeted for.

s/targetBranch/targetVersion/g

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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] How to work with branches

[Stephen Connolly]

On Sun 19 Mar 2017 at 20:05, Fred Cooke  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- - 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

Re: [DISCUSS] How to work with branches

[Fred Cooke]

No need to cherry-pick, that should be a rare operation.

Clean up the branch and prepare it for a fast forward with high quality
commits, then just push it when it's ready and passes scrutiny and tests.

+1 on ugly masters. Last time I looked at the docker project the displayed
history showed 15 or so merge commits and NO content commits. Useless.

On 20 March 2017 at 11:46, Hervé BOUTEMY  wrote:

> until now, target version was managed through Jira issue: I'm not convinced
> putting the info in an additional place like branch name will help keep
> info
> in sync
>
> For the merge idea, the "target branch" concept seems too much for me: if
> the
> branch was automatically locally rebased on master, this would be simpler
> and
> sufficient IMHO
>
> And I completely dislike merge commits and remaining branches in master:
> commits should be cherry picked and merge commit totally avoided IMHO.
> Merge commits (and complex history retained from this practice) is a big
> pain
> point to me to have a clear master history
>
> Regards,
>
> Hervé
>
> Le dimanche 19 mars 2017, 17:34:21 CET Stephen Connolly a écrit :
> > 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- - 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!
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] How to work with branches

[Hervé BOUTEMY]

until now, target version was managed through Jira issue: I'm not convinced 
putting the info in an additional place like branch name will help keep info 
in sync

For the merge idea, the "target branch" concept seems too much for me: if the 
branch was automatically locally rebased on master, this would be simpler and 
sufficient IMHO

And I completely dislike merge commits and remaining branches in master: 
commits should be cherry picked and merge commit totally avoided IMHO.
Merge commits (and complex history retained from this practice) is a big pain 
point to me to have a clear master history

Regards,

Hervé

Le dimanche 19 mars 2017, 17:34:21 CET Stephen Connolly a écrit :
> 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- - 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!



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] How to work with branches

[Fred Cooke]

How are branches noisy? Promiscuous automated emails or some such?

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?

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).

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

On 20 March 2017 at 06:34, Stephen Connolly  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- - 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!
>

[DISCUSS] How to work with branches

[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- - 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!