Comments inline.
On 27/04/2013 11:41 AM, Greg Trasuk wrote:
Hi all:
Peter brings up an excellent point here, something that I've found
troubling in this release process. It is exceedingly difficult to
identify what changes have been made to the code, and why, or to trace
changes to JIRA issues. By extension it's very hard to identify which
revisions have been or should be applied to a branch, and what bugs have
been fixed in a branch.
Jira can link commits to an issue when you add the issue reference eg:
RIVER-403 to the commit comment.
However it relies on developers discipline, I don't have any answers I'm
afraid.
Just throwing this out for discussion - I'm coming around to the view
that we should adopt a policy of review-then-commit for changes to the
trunk and any release branches.
I've found it very difficult to have people peer review code, Dan did
perform some review, Fred Oliver used to be quite helpful (would make
suggestions for improvement) he was the only one who read the code
voluntarily and made comments, participation has been relatively low.
If participation increases this might be feasible.
The brittle nature of the tests (not so brittle in qa_refactoring
anymore) has discouraged at least one developer recently. There's a
fine balance, on one hand we want to track the thoughts of developers
and the reasons why they've made certain changes, but we don't want to
discourage participation either. Perhaps someone on the list might have
some experience with these problems. Jeff might have some more info
regarding git, I don't have any experience with git myself.
There are changes that Sim made to the trunk that I need to incorporate
into qa_refactoring, I had always planned to do that when tests stabilised.
Regards,
Pete.
I'm thinking that when someone does a bug fix or some work on a feature,
we should:
- do that work on a branch (call this the 'working' branch for this
discussion)
- package that work as either a patch or a list of revisions to merge
- put that package into a JIRA issue (which may already exist if we're
doing a bug fix).
- identify which branches the patch should be applied to
- review, discuss, and vote on the patch in the JIRA issue
- then apply the patch to those branches, referencing the JIRA issue in
the commit messages
- ideally, terminate the working branch. Future work proceeds on a new
branch from the trunk.
That way, it would be easy to trace changes in the trunk and release
branches, and hence to generate an accurate release notice.
Also, I'd suggest that the "FIX_VERSION" field in JIRA belongs to the
release manager for a given release - he or she will update the field in
the requisite issues as part of the release process.
Your thoughts? Anyone familiar with any other projects' practices?
Greg Trasuk.
On Fri, 2013-04-26 at 16:58, Peter Firmstone wrote:
Checked RIVER-[404], the jtreg test certs still fail.
It's been fixed in trunk, we need to remove it from the release notes
for 2.2.1
I don't think River-[403] or River-[417] made it into 2.2.1 either.
I think these issues were marked as completed as part of a previous
release process that was left unfinished.
River-[403] really needs to be included though.
Regards,
Peter.
