On 3 June 2011 21:54, Phil Steitz <phil.ste...@gmail.com> wrote: > On 6/3/11 1:15 PM, sebb wrote: >> On 3 June 2011 20:48, Gary Gregory <garydgreg...@gmail.com> wrote: >>> On Fri, Jun 3, 2011 at 2:53 PM, sebb <seb...@gmail.com> wrote: >>> >>>> On 3 June 2011 19:21, Gary Gregory <garydgreg...@gmail.com> wrote: >>>>> +1. >>>>> >>>>> I would like to see the JIRA report be only for this release instead of >>>> the >>>>> whole pile. >>>> That's the default setting for the plugin. >>>> >>> Not a very useful default then :( >>> >>> Running vs. the previous release is a nice sanity check for the changes >>> report which must be manually maintained. >> That would require all JIRA issues to be marked with the correct Fix >> version(s). >> I'm not sure all components have been maintaining the fix issue fields. > > We should all be doing that, IMO. It really helps when > troubleshooting / researching later if the correct fix and affected > versions are maintained. It also serves as a de facto release plan > when you maintain fix versions on the inventory of open issues.
I entirely agree that we should be maintaining the fix versions. But I was just pointing out that the report does not automatically show what has been fixed for a particular release - it's only as reliable as the input data. >> Also, either the JIRA issues must also be closed (not just resolved) >> or the report must be configured to show resolved issues. >> The work-flow tends to be that issues are closed after a release is >> made - if ever. > > I think that is also best practice - resolve when fixed in SVN, > close when fix version is released. > > Phil >>> Gary >>> >>> >>>> I'd not noticed the report before. >>>> Not sure it's all that useful - hardly any other components use it: >>>> >>>> ./sandbox/digester3/jira-report.html >>>> ./digester/commons-digester-2.1/jira-report.html >>>> ./digester/jira-report.html >>>> ./compress/jira-report.html >>>> ./email/jira-report.html >>>> ./fileupload/jira-report.html >>>> ./net/jira-report.html >>>> >>>> Also it only shows closed issues by default. >>>> >>>> I'm inclined to delete it from the next release. >>>> >>>>> Shouldn't the Clirr report be vs. 3.0 instead of 2.2? >>>>> >>>> I deliberately included 3.0 in the Release Notes and Clirr report, >>>> because the release is basically just a corrected version of 3.0. >>>> >>>> As it is being released soon after 3.0, there will be many users who >>>> will need to skip 3.0 and move from 2.x to 3.0.1. >>>> >>>> I meant to mention that in the original VOTE e-mail, sorry. >>>> >> --------------------------------------------------------------------- >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
