On 1/3/15 11:48 AM, sebb wrote: > On 3 January 2015 at 18:38, Gilles <[email protected]> wrote: >> On Sat, 3 Jan 2015 18:01:22 +0000, sebb wrote: >>> On 3 January 2015 at 12:32, Benedikt Ritter <[email protected]> wrote: >>>> Hello Carl, >>>> >>>> 2015-01-03 2:49 GMT+01:00 Carl Hall <[email protected]>: >>>> >>>>> 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.
I disagree and will continue to assign fix versions for the components that I work on prospectively. These can, and do, change as issues get investigated, releases get planned and cut, etc. Letting issues pile up with no fix version is a "project smell" IMO. The ones that are going to end up "WONT_FIX" should be resolved that way ASAP instead of just letting them sit. The fix version tells the community something and, as Gilles and I said above, it is useful in release planning. Phil > >> Gilles >> >>>> [...] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
