kfogel@collab.net wrote:
> Branko Čibej <brane@xbc.nu> writes:
>> Some bugs are specific to a particular version, or (as Julian points
>> out) to a particular OS. Also, Issuezilla doesn't only contain
>> defects, it also contains tasks, and those are even more often
>> version-specific.
>>
>> Certainly, the version (and OS and platform) fields should be reviewed
>> and changed where necessary, but blindly changing /everything/ is a
>> mistake.
>
> Max has spent the most time in the issue tracker of any of us lately
> -- if he's saying that the Version field is generally useless and/or a
> source of misinformation, I'm inclined to believe him :-).
>
> However, if the problem is simply that we (developers who process
> incoming issues) need to remember to set the Version field to
> something meaningful, we could start doing that, it wouldn't add
> significant overhead. We could always set it to "---" when there's no
> better value available.
>
> Max, is there some reason this solution wouldn't work? I just hate to
> throw out the baby with the bathwater, on the other hand I don't want
> to bite the hand that feeds the mouths of the kine who tread the grain.
> Or something like that.
The problem is that it is presented to the requestor as " Found in version:
" - so they tend to set it - but the fact that it has been found in a
particular version doesn't *usually* mean that it is unique to that version.
We do not have many versions simultaneously active, in which we
independently fix bugs. Thus, having a version field attached to a bug
doesn't really mean anything. Whatever version a bug is reported in, we
generally only care whether it still exists in trunk or not.
If anyone can define a useful purpose for the version field, I'd be happy to
keep it. But at the moment, we aren't using it in any way, and it's just
getting filled in with no guiding policy by the initial filer of the issues.
So, either we need some sort of policy for what the version field actually
means, or we should get rid of it. I don't see any useful piece of
information we can track in a choose-one-option field, so I'm inclined to
get rid of it.
If someone *can* see a good use for it, then I'd be happy to keep it on.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 25 19:50:12 2005