Quantcast

closing vs resolving issues

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

closing vs resolving issues

Justin Deoliveira
Hey all,

Another jira inconsistency i notice is that some people close issues, while others resolve them. The majority tend to resolve and then we do a sort of batch close at a later date. As far as I can tell it is mostly Ben that by default closes the issue. Not saying this is wrong at all, but i would like to standardize to remove inconsistency.

As i understand it the workflow is usually as follows. Someone opens an issue. A developer works on issue and when satisfied with the fix marks it as resolved. The original creator of the issue then confirms the issue is fixed and marks the issue as closed.

One issue i have with closing issues is that they can't be edited unless re-opened. Which is a problem for releases, for example with fixVersions that are not set. So I wonder if we should hold off on closing issues until after the release has been published.

Once we decide what is best i will document our "jira policy" in the developer guide.

Thanks!

-Justin

--
Justin Deoliveira
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

Alessio Fabiani-2
Agree on holding off closing the issues.

Regards,
        Alessio.

-------------------------------------------------------
Ing. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: (+39) 0584 96.23.13
fax:     (+39) 0584 96.23.13
mobile:(+39) 331 62.33.686

http://www.geo-solutions.it
http://geo-solutions.blogspot.com
http://www.linkedin.com/in/alessiofabiani
https://twitter.com/alfa7961
http://twitter.com/geosolutions_it
-------------------------------------------------------



On Tue, May 22, 2012 at 3:56 PM, Justin Deoliveira <[hidden email]> wrote:
Hey all,

Another jira inconsistency i notice is that some people close issues, while others resolve them. The majority tend to resolve and then we do a sort of batch close at a later date. As far as I can tell it is mostly Ben that by default closes the issue. Not saying this is wrong at all, but i would like to standardize to remove inconsistency.

As i understand it the workflow is usually as follows. Someone opens an issue. A developer works on issue and when satisfied with the fix marks it as resolved. The original creator of the issue then confirms the issue is fixed and marks the issue as closed.

One issue i have with closing issues is that they can't be edited unless re-opened. Which is a problem for releases, for example with fixVersions that are not set. So I wonder if we should hold off on closing issues until after the release has been published.

Once we decide what is best i will document our "jira policy" in the developer guide.

Thanks!

-Justin

--
Justin Deoliveira
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

Ben Caradoc-Davies
In reply to this post by Justin Deoliveira
On 22/05/12 21:56, Justin Deoliveira wrote:
> As far as I can tell it is mostly Ben that by default closes the issue.

I usually only close issues I reported, or those confirmed fixed by my
team or partners, or where I am manually synchronising codehaus with my
group's private Jira (used for iteration planning).

An alternative practice is that used in my group's private Jira; closing
is a management review activity and is not in general performed by
developers. This is might not be appropriate for an open source project
as we have limited management resources.

In a nutshell, let us follow the Jira definition: "Resolved — A
Resolution has been identified or implemented, and this issue is
awaiting verification by the reporter. From here, issues are either
'Reopened' or are 'Closed'."

So closed means verified complete by the reporter (or some other
responsible party).

Kind regards,

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

Justin Deoliveira
Hey Ben,

On Tue, May 22, 2012 at 8:09 PM, Ben Caradoc-Davies <[hidden email]> wrote:
On 22/05/12 21:56, Justin Deoliveira wrote:
As far as I can tell it is mostly Ben that by default closes the issue.

I usually only close issues I reported, or those confirmed fixed by my team or partners, or where I am manually synchronising codehaus with my group's private Jira (used for iteration planning).

An alternative practice is that used in my group's private Jira; closing is a management review activity and is not in general performed by developers. This is might not be appropriate for an open source project as we have limited management resources.

In a nutshell, let us follow the Jira definition: "Resolved — A Resolution has been identified or implemented, and this issue is awaiting verification by the reporter. From here, issues are either 'Reopened' or are 'Closed'."

Right it makes sense, again my issue is that closing issues before the associated fixCersion is released is a real pain when realeasing in jira. I will bring this up as a topic for discussion in our next IRC meeting. 

So closed means verified complete by the reporter (or some other responsible party).

Kind regards,

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre



--
Justin Deoliveira
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

Ben Caradoc-Davies
Oh, I see the problem: an issue might even have correctly set fixVersion
at the time, be closed, and we might add an extra release or skip a
beta, rendering existing fixVersions incorrect, forcing reopening of the
issues. I think this is one for Monday's meeting.

This is becoming cumbersome. How about using fixVersion for branches
only and deducing the changes with some clever JQL? Does JQL support
joins? This way madness lies ...

On 23/05/12 10:41, Justin Deoliveira wrote:
> Right it makes sense, again my issue is that closing issues before the associated fixCersion is released is a real pain when realeasing in jira. I will bring this up as a topic for discussion in our next IRC meeting.

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

Justin Deoliveira

On Tue, May 22, 2012 at 9:01 PM, Ben Caradoc-Davies <[hidden email]> wrote:
Oh, I see the problem: an issue might even have correctly set fixVersion at the time, be closed, and we might add an extra release or skip a beta, rendering existing fixVersions incorrect, forcing reopening of the issues. I think this is one for Monday's meeting.
Exactly.
 

This is becoming cumbersome. How about using fixVersion for branches only and deducing the changes with some clever JQL? Does JQL support joins? This way madness lies ...
Come on... is closing issues before a release really that important? 


On 23/05/12 10:41, Justin Deoliveira wrote:
Right it makes sense, again my issue is that closing issues before the associated fixCersion is released is a real pain when realeasing in jira. I will bring this up as a topic for discussion in our next IRC meeting.

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre



--
Justin Deoliveira
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

Ben Caradoc-Davies
So what does a bug reporter do if they confirm the bug is fixed in a
nightly? You seem to be suggesting that they do not provide the
confirmed-fixed feedback usually indicated in Jira by closing the issue.

To make closing part of the release process (and I think that is a
really good idea!) we need to start treating resolved as being
confirmed-fixed (instead of closing the issue). This differs from the
Jira manual. I think this is a worthwhile, but will require Jira user
education. We need to identify the two use-cases: (1) reporter feedback,
and (2) release manager changelog generation. In my view, we can't use
"Closed" for both. You are asking us to choose (2). I agree.

On 23/05/12 11:35, Justin Deoliveira wrote:
> Come on... is closing issues before a release really that important?

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

geowolf
In reply to this post by Justin Deoliveira
On Tue, May 22, 2012 at 3:56 PM, Justin Deoliveira <[hidden email]> wrote:
Hey all,

Another jira inconsistency i notice is that some people close issues, while others resolve them. The majority tend to resolve and then we do a sort of batch close at a later date. As far as I can tell it is mostly Ben that by default closes the issue. Not saying this is wrong at all, but i would like to standardize to remove inconsistency.

As i understand it the workflow is usually as follows. Someone opens an issue. A developer works on issue and when satisfied with the fix marks it as resolved. The original creator of the issue then confirms the issue is fixed and marks the issue as closed.

One issue i have with closing issues is that they can't be edited unless re-opened. Which is a problem for releases, for example with fixVersions that are not set. So I wonder if we should hold off on closing issues until after the release has been published.

Works for me. I'm guilty of mass closing resolved issues, when I'm in "jira gardening mode", aka go through old issues and see if there is any that is solved, but nobody noticed, I also happen to close resolved issues that have had no comments for the last month or so. I can stop doing that.

As for the reporter closing the issues, I honestly see no problem with that, but indeed we need the developer closing the issue to adjust the "fix for" to match the branches the patch was committed on.

Btw, when I do close a issue that is a "won't fix" or a "cannot reproduce" or an old issue that was resolved in the meantime, but there's no telling when, I just remove all the "fix for" to avoid having that issue get into changelogs, since it effectively represents no change.
If we get a policy on how to handle issue closing the above practice needs discussion as well

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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

Justin Deoliveira
In reply to this post by Ben Caradoc-Davies
Maybe I don't use jira enough but I generally don't see users that actually close issues. If I look at jira at every issue resolved this year I see 213 issues. 


If i look at those that have been closed i only see 30 issues.


Seems like quite a minority to me.

I think that the resolve - close workflow works great for internal development teams that use jira, but those teams usually have dedicated QA people whose job is to go through and verify all issues, marking them as closed. Or the developers have dedicated phases of an iteration to go and verify resolved issues. I don't really see this on any of the open source projects i am a part of.

So yes, what i am proposing is that we leave issues as resolved until they are attached to a released version that has been released in jira. At that time we can do a mass close of all of them. If a user verifying a fix finds its not actually fixed the issue will be re-opened anyways.

On Tue, May 22, 2012 at 9:57 PM, Ben Caradoc-Davies <[hidden email]> wrote:
So what does a bug reporter do if they confirm the bug is fixed in a nightly? You seem to be suggesting that they do not provide the confirmed-fixed feedback usually indicated in Jira by closing the issue.

To make closing part of the release process (and I think that is a really good idea!) we need to start treating resolved as being confirmed-fixed (instead of closing the issue). This differs from the Jira manual. I think this is a worthwhile, but will require Jira user education. We need to identify the two use-cases: (1) reporter feedback, and (2) release manager changelog generation. In my view, we can't use "Closed" for both. You are asking us to choose (2). I agree.


On 23/05/12 11:35, Justin Deoliveira wrote:
Come on... is closing issues before a release really that important?

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre



--
Justin Deoliveira
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

Justin Deoliveira
In reply to this post by geowolf


On Wed, May 23, 2012 at 1:47 AM, Andrea Aime <[hidden email]> wrote:
On Tue, May 22, 2012 at 3:56 PM, Justin Deoliveira <[hidden email]> wrote:
Hey all,

Another jira inconsistency i notice is that some people close issues, while others resolve them. The majority tend to resolve and then we do a sort of batch close at a later date. As far as I can tell it is mostly Ben that by default closes the issue. Not saying this is wrong at all, but i would like to standardize to remove inconsistency.

As i understand it the workflow is usually as follows. Someone opens an issue. A developer works on issue and when satisfied with the fix marks it as resolved. The original creator of the issue then confirms the issue is fixed and marks the issue as closed.

One issue i have with closing issues is that they can't be edited unless re-opened. Which is a problem for releases, for example with fixVersions that are not set. So I wonder if we should hold off on closing issues until after the release has been published.

Works for me. I'm guilty of mass closing resolved issues, when I'm in "jira gardening mode", aka go through old issues and see if there is any that is solved, but nobody noticed, I also happen to close resolved issues that have had no comments for the last month or so. I can stop doing that.

Totally fine with this as it happens after the release, often well after. 
 
As for the reporter closing the issues, I honestly see no problem with that, but indeed we need the developer closing the issue to adjust the "fix for" to match the branches the patch was committed on.

Btw, when I do close a issue that is a "won't fix" or a "cannot reproduce" or an old issue that was resolved in the meantime, but there's no telling when, I just remove all the "fix for" to avoid having that issue get into changelogs, since it effectively represents no change.
If we get a policy on how to handle issue closing the above practice needs discussion as well

Right, i think this makes sense too.  

Cheers
Andrea

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


Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: <a href="tel:%2B39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313
fax:      <a href="tel:%2B39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313
mob:    <a href="tel:%2B39%C2%A0339%208844549" value="+393398844549" target="_blank">+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
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

Ben Caradoc-Davies
In reply to this post by Justin Deoliveira
On 23/05/12 21:08, Justin Deoliveira wrote:
> So yes, what i am proposing is that we leave issues as resolved until
> they are attached to a released version that has been released in jira.

We might want to wait until both stable and trunk versions have been
released. For example, I don't think an issue should be closed if
fixVersion is set for 2.1.5 and 2.2-beta3 before both have been released.

What about branch versions? Is there any point in having fixVersion
2.1.x or 2.2.x? Or is it just clutter?

Kind regards,

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

geowolf
On Thu, May 24, 2012 at 5:10 AM, Ben Caradoc-Davies <[hidden email]> wrote:
On 23/05/12 21:08, Justin Deoliveira wrote:
> So yes, what i am proposing is that we leave issues as resolved until
> they are attached to a released version that has been released in jira.

We might want to wait until both stable and trunk versions have been
released. For example, I don't think an issue should be closed if
fixVersion is set for 2.1.5 and 2.2-beta3 before both have been released.

What about branch versions? Is there any point in having fixVersion
2.1.x or 2.2.x? Or is it just clutter?

Imho it's just clutter. 

More in general, most of the issues have a "fix for" version that is 
purely a wish, a issue gets fixed if it's a "stop the world" thing or 
if it has resourcing behind it (core developer spare time, company, 
or an occasional contributor with a patch).

From that point of view I'd wish that people stopped flagging the
"fix for" unless there is something backing the work to fix the issue,
otherwise people look at jira and say "oh, this one is scheduled for
2.1.4" when that one has been around since, maybe, 2.1-beta1,
has just been moved forward over and over, and it's not
really going to be fixed anytime soon (just making it up, don't know
if there is any issue in the state I've described, but I've seen many
being just moved forward repeatedly).

Don't really think it's feasible, nobody can know if a report has
backing when it's opened, but I find it troublesome that we're
sending out the wrong message

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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

jody.garnett
From that point of view I'd wish that people stopped flagging the
"fix for" unless there is something backing the work to fix the issue,
otherwise people look at jira and say "oh, this one is scheduled for
2.1.4" when that one has been around since, maybe, 2.1-beta1,
has just been moved forward over and over, and it's not
really going to be fixed anytime soon (just making it up, don't know
if there is any issue in the state I've described, but I've seen many
being just moved forward repeatedly).
I have had a look at the administration options; and I think Jira could be configured to hide that field until the last two stages of the workflow (Resolved/Closed).

So the workflow would be something like:
0) Issue is created, gets patched, and is eventually ...
1) marked as resolved … fill in the "fix for" version at this time
2) Leave it open while waiting for confirmation from user list; and close the issue if you get confirmation
3) In the real world - close the issues when the release goes out

I no longer have super-admin access on Jira; but I can see the admin options that would let 

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

Justin Deoliveira
I do like idea of not setting fix version when filing an issue, but it still doesn't address my initial concern with closing issues. Anyways, good topic for monday.

On Thu, May 24, 2012 at 5:15 AM, Jody Garnett <[hidden email]> wrote:
From that point of view I'd wish that people stopped flagging the
"fix for" unless there is something backing the work to fix the issue,
otherwise people look at jira and say "oh, this one is scheduled for
2.1.4" when that one has been around since, maybe, 2.1-beta1,
has just been moved forward over and over, and it's not
really going to be fixed anytime soon (just making it up, don't know
if there is any issue in the state I've described, but I've seen many
being just moved forward repeatedly).
I have had a look at the administration options; and I think Jira could be configured to hide that field until the last two stages of the workflow (Resolved/Closed).

So the workflow would be something like:
0) Issue is created, gets patched, and is eventually ...
1) marked as resolved … fill in the "fix for" version at this time
2) Leave it open while waiting for confirmation from user list; and close the issue if you get confirmation
3) In the real world - close the issues when the release goes out

I no longer have super-admin access on Jira; but I can see the admin options that would let 

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel




--
Justin Deoliveira
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

Ben Caradoc-Davies
In reply to this post by jody.garnett
On 24/05/12 19:15, Jody Garnett wrote:
> 2) Leave it open while waiting for confirmation from user list; and
> close the issue if you get confirmation

No, no, (2) is the bit Justin wants to prevent. What if you tag an
upcoming fixVersion of 2.2-beta3 and we skip straight to 2.2-rc1? Now
some poor release manager has to re-open the issue and re-resolve it to
change the fixVersion.

What Justin wants to do (and I support) is that issues are only closed
when a release is made. We are giving up the ability to use issue closed
state to indicate confirmation that the problem is fixed. We can either
wait for this before resolving or resolve if we are pretty sure and go
back to open/in-progress if the problem is re-raised.

The proposed workflow is your (0), (1), and then (3) when all the stable
and trunk releases affected by the change are complete.

(2) is way out:
http://www.youtube.com/watch?v=xOrgLj9lOwk

Kind regards,

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

Ben Caradoc-Davies
In reply to this post by geowolf
+1. I think we need to ditch the use of fixVersion for end-user
pleading. Only set fixVersion if you or your team are working on the
issue and are committed to including it in that release. This is
Justin's use-case of a developer asking a release manager to wait for a
particular fix.

On 24/05/12 16:24, Andrea Aime wrote:
>  From that point of view I'd wish that people stopped flagging the
> "fix for" unless there is something backing the work to fix the issue

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

fgdrf
Quite interesting discussion! 

Some notes from my point of view:

1+ for resolved -> close workflow, in this case everybody has a chance to see whats fixed and properly untested (walkthrough), it would be a kind of checklist which parts of an upcoming release should be tested.

However, Do you know, that its possible to change workflows in JIRA [1], [2]. With this in mind, and hopefully its possible to define project specific workflows, it would be a great to define transition between different states:

My favorite would look like this:

  open --> close (wont fix)
  open --> close (its not a bug)
  open --> close (duplicate to)
  open --> resolve (fixed and the fixed version will be set if the release is identified, properly more than once if applied to different branches) 
  resolve --> close (kind of check "Yes it works")
  resolve --> reopen (Hmm, sorry good try but bug is not fixed)

Is it possible do administrate the JIRA instance (properly for both, geoserver and geotools but independently)

Cheers,
Frank

[1]  http://www.slideshare.net/GoAtlassian/c6-mastering-jira-workflows 

2012/5/25 Ben Caradoc-Davies <[hidden email]>
+1. I think we need to ditch the use of fixVersion for end-user
pleading. Only set fixVersion if you or your team are working on the
issue and are committed to including it in that release. This is
Justin's use-case of a developer asking a release manager to wait for a
particular fix.

On 24/05/12 16:24, Andrea Aime wrote:
>  From that point of view I'd wish that people stopped flagging the
> "fix for" unless there is something backing the work to fix the issue

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: closing vs resolving issues

jody.garnett
However, Do you know, that its possible to change workflows in JIRA [1], [2]. With this in mind, and hopefully its possible to define project specific workflows, it would be a great to define transition between different states:
Yes; I mentioned this before.

For GeoTools we have a few customisations in effect; including our description of the different priority settings. For uDig we experimented with a QA state.
Is it possible do administrate the JIRA instance (properly for both, geoserver and geotools but independently)
Yes it … was.

I no longer have the admin access required. To make a change raise a HAUS ticket.
 
Jody

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Loading...