On 3 January 2015 at 18:38, Gilles <gil...@harfang.homelinux.org> wrote: > On Sat, 3 Jan 2015 18:01:22 +0000, sebb wrote: >> >> On 3 January 2015 at 12:32, Benedikt Ritter <brit...@apache.org> wrote: >>> >>> Hello Carl, >>> >>> 2015-01-03 2:49 GMT+01:00 Carl Hall <carl.h...@gmail.com>: >>> >>>> Thanks, Benedikt and Mark. I have made my first commit (woo!) and will >>>> start working through JIRA to clear out the easy stuff. Is there any >>>> rule >>>> (by writ or general practice) for closing tickets that haven't seen any >>>> action in some time? Seems like old tickets that haven't moved in a >>>> while >>>> (e.g. [1]) might be candidates for "reopen if this becomes interesting >>>> again." >>>> >>> >>> There is no strict procedure for this kind of issues. In your particular >>> case, Sebb has already commented that this addition doesn't really make >>> sense. Since the contributor hasn't reacted on the comment, I think it's >>> okay to close this issue as Won't fix. >>> Note, that we only set the Fix Version for issues that have actually been >>> implemented. So when an issue is closed as Won't fix, duplicate, invalid >>> etc, we remove the fix version, so that it doesn't show up in the reports >>> for this version. >> >> >> In many components the fix version is only added when the fix is >> actually implemented. >> i.e. it is treated as "has been fixed in version x" rather than "this >> is an issue to be fixed in version x" >> > > JIRA allows both (when the issue is created and when it is resolved). > Setting the "Fix version" allows a clearer view of what needs to be > done before the next release can happen.
But there is only a single field, and JIRA workflow does not guarantee that the Fix version is checked for validity upon resolution. If there are several pending releases, the original proposed fix may make it into an earlier actual version. And vice-versa. I find it better to set the fix when resolving the issue. Generally one has a better idea of the release version at that point, whereas an issue may be created and not fixed for several releases. > Gilles > >>> [...] > > > --------------------------------------------------------------------- > 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
