maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Heinz Marbaise <>
Subject Re: [DISCUSS] How to work with branches
Date Mon, 20 Mar 2017 07:17:42 GMT

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 

If someone needs some special attention for a particular issue this can 
be done via the mailing list....Or 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-XXXX - 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 

> 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:
For additional commands, e-mail:

View raw message