On 6/4/11 8:06 AM, sebb wrote: > I've been doing some experimentation with the JIRA report. > > The following configuration IMO produces a reasonable-looking report [1]: > > <onlyCurrentVersion>false</onlyCurrentVersion> > <columnNames>Fix Version,Key,Summary,Type,Resolution,Status</columnNames> > <!-- Sort cols have to be reversed in JIRA 4 --> > <sortColumnNames>Key DESC,Type,Fix Version DESC</sortColumnNames> > <resolutionIds>Fixed</resolutionIds> > <statusIds>Resolved,Closed</statusIds> > <!-- Don't include sub-task --> > <typeIds>Bug,New Feature,Task,Improvement,Wish,Test</typeIds> > > As mentioned elsethread, issues should be marked as resolved with the > appropriate fix version when fixed in SVN; and issues should only be > closed after the release has been published. > > What is not so clear is how to handle duplicate reports. > If these are to be included in the report, then the Fix versions will > have to be maintained. > > If not, then it's important that all duplicates are resolved as > Duplicate rather than Fixed.
Sounds reasonable to me to either maintain the fix version and resolve simultaneously as fixed or just CLOSE one as duplicate. I can imagine (and I think I may done it) scenarios where the underlying cause of two issues is the same, so it is correct to mark one as duplicate; but the issue impacting users appears to be different, or at least complementary. In that case, I like to keep both issues open and resolve them both as fixed when the underlying problem is fixed in svn, closing both on release with the fix version of the release. In cases where the reported problem really is the same - i.e., there is nothing that one report adds to what has already been reported, I think CLOSEing one as duplicate is appropriate. Phil > Views? > > [1] http://people.apache.org/~sebb/NET_3_0_1RC3/jira-report.html > Additionally filtered as follows: > <fixVersionIds>3.0.1,3.0,2.2</fixVersionIds> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
