commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: JIRA report usefulness (was: [VOTE] Release Commons NET 3.0.1 based on RC3)
Date Fri, 03 Jun 2011 20:54:48 GMT
On 6/3/11 1:15 PM, sebb wrote:
> On 3 June 2011 20:48, Gary Gregory <garydgregory@gmail.com> wrote:
>> On Fri, Jun 3, 2011 at 2:53 PM, sebb <sebbaz@gmail.com> wrote:
>>
>>> On 3 June 2011 19:21, Gary Gregory <garydgregory@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.
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message