Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <517B70D0.5050107@zeus.net.au>
Date: Sat, 27 Apr 2013 16:31:44 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
 rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: Review-then-commit.  Was: Re: 2.2 Release status
References: <1366984577.8176.82.camel@cameron>	 <517AEA5F.7020207@zeus.net.au>
 <1367026918.8176.167.camel@cameron>
In-Reply-To: <1367026918.8176.167.camel@cameron>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.