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