On Mon, May 21, 2012 at 10:03 PM, Ben Caradoc-Davies <
[email protected]> wrote:
> Justin,
>
> short version: I support both (a) and (b).
>
> It took me years to figure out how fixversion is used; we should explain
> what it is for and promulgate this information. One problem is that issue
> reporters set fixversion as an appeal to maintainers and this may not be
> corrected.
>
> From my understanding, we use fixversion for two distinct purposes:
>
> (1) Identifying release blockers (your previous example of open issues
> with priority>=critical with fixversion set to the upcoming release). This
> is the aspirational interpretation ("should be fixed for version").
>
> (2) Generating release changelog. This is the historical record
> interpretation ("was fixed for version").
>
> In my view, it is the responsibility of whoever is resolving or closing an
> issue to set fixversion for the branch and upcoming release. Some
> developers might not know this. Some developers might not realise that it
> is different from affects version. Some may be reluctant to change it if
> set by a senior.
>
> It would be easier if a kind Jira admin would arrange for the next trunk
> and stable release versions to be near the top of the list.
>
> Some fixversions are mistakes. It is quite easy to set when
> affects-version is meant.
>
> Yup, agreed on all fronts here. I will also go into jira and clean up the
versions, there are lots of old unreleased versions in there that are
cluttering things up.
> Kind regards,
> Ben.
>
>
>
> On 22/05/12 11:28, Justin Deoliveira wrote:
>
>> Hey folks,
>>
>> As I wrap up the 2.2-beta2 release i am looking at the changelog for
>> 2.2-beta2 and something is a miss.
>>
>> http://jira.codehaus.org/**secure/ReleaseNote.jspa?**
>> projectId=10311&version=18437<http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10311&version=18437>
>>
>> Just over a dozen issues... doesn't sound right and indeed it is not.
>> What's happening is that issues resolved are not being marked with a
>> fixVersion or marked with a fixVersion on 2.1.x only even though the fix
>> occurs on trunk as well.
>>
>> First question. Is this intentional? If the answer is no second question
>> is can we make it jira policy to (a) always mark the fixVersion and (b)
>> mark it to reflect all branches a fix was done on?
>>
>> Thanks.
>>
>> -Justin
>>
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>>
>>
>>
> --
> Ben Caradoc-Davies <[email protected]>
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
