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.


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


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

Reply via email to