[Geoserver-devel] fixVersion in jira

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

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.

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.

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

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 <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

On Tue, May 22, 2012 at 5:28 AM, Justin Deoliveira <jdeolive@anonymised.com> 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

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.

Hum… probably some material error, not a policy (for the ones I’ve seen that I’ve closed it was a matter of an oversight, not adjusting the fix for version for issues that were meant to be fixed in 2.1.x and ended up landing only on trunk, such as the png8 + alpha improvements).

As an aside, wondering if 2.2-beta2 did exist as a version when the jiras were created and/or closed? (the fix for version can be adjusted when closing an issue)

Cheers
Andrea


Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

On Mon, May 21, 2012 at 10:03 PM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> 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

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 Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

On Tue, May 22, 2012 at 2:29 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, May 22, 2012 at 5:28 AM, Justin Deoliveira <jdeolive@anonymised.com> 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

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.

Hum… probably some material error, not a policy (for the ones I’ve seen that I’ve closed it was a matter of an oversight, not adjusting the fix for version for issues that were meant to be fixed in 2.1.x and ended up landing only on trunk, such as the png8 + alpha improvements).

As an aside, wondering if 2.2-beta2 did exist as a version when the jiras were created and/or closed? (the fix for version can be adjusted when closing an issue)

I believe it did… i am fairly certain i created it when doing the 2.2-beta1 release. I could be wrong though.

Cheers
Andrea


Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.