On 05/11/2011 12:36 AM, Ross Gardler wrote:
On 10/05/2011 19:13, Franklin, Matthew B. wrote:
No problem. The biggest problem now is closing issues. Do we want to have
someone other than the person who worked the issue ( and marked it resolved)
close it?
Personally I prefer issues to be verified by someone other than the person who
did the work. I think our community here is large enough to allow this to
happen.
However, doing so does add overhead on the community.
The way we do it on some projects is that we make it part of the testing cycle
for a release. That is, once a release candidate has been packaged we ask
community members (need not be committers) to test new features and bug fixes
that have been resolved but not closed.
This does mean that issues remain in the resolved state for some time, but it
also means we have a fairly solid testing plan for release candidates. Assuming
that the new features/bug fixes have been tested during the development cycle
there should be no reason for this to slow down a release (significantly).
What do others think?
+1 in general.
However, trivial issues not of the type which need to be reviewed by others imo
can and be closed whenever deemed done.
And if before a release cycle a non-trivial issue already is properly reviewed
and tested by others (committers and/or others from the community), the same may
apply.
Monitoring JIRA state changes is easy as they are reported to the list so
everyone can/should be aware what goes on.
Using common sense before and above strict ruling :)
Very important imo is that all (or at least relevant) svn commits should have
the corresponding JIRA issue logged. Not specifying a JIRA issue should be only
be reserved for trivial changes.
At Hippo we actually have a svn commit hook requiring us to always specify an
open JIRA issue, including a reserved (always open) 'Trivial Changes' issue.
As best practice, I'd like to suggest not only specifying the JIRA issue, e.g.
RAVE-123, but also the actual link to the issue so its very quick to open it up
while reviewing code changes, like:
RAVE-123: <(short) summary of issue title>
http://issues.apache.org/jira/browse/RAVE-123
- short change description 1
- ...
- short change description n
Regards,
Ate
Ross
Sent from my mobile device
-----Original Message-----
From: Ross Gardler [mailto:[email protected]]
Sent: Tuesday, May 10, 2011 11:34 AM Eastern Standard Time
To: [email protected]
Subject: Issue Triage (Thanks Matt)
Matt,
Thanks for looking after the issue tracker for us. It's an important job
that so often gets neglected.
We should all chip in to this kind of task whenever we have a few
moments spare for Rave.
JIRA allows quite complex filters to be set up, I'm happy to set any up
that the team think might be useful. For example:
"Issues with no activity for> 30 days"
Ross
