Branko Čibej wrote:
> Max Bowsher wrote:
>
>> IssueZilla has a version field.
>>
>> Ours used to have only a single possibility "all".
>>
>> Now, is also has "---", "trunk", "1.0.x", and "1.1.x".
>>
>> But, we don't seem to actually be using this, it's just accumulating
>> whatever the initial reporter set it too, and then being totally
>> ignored by us.
>>
>> I don't think the version a bug applies to can be adequately expressed
>> in a simple choose-single-option field.
>>
>> Unless anyone can come up with a way the field can be useful, I intend
>> to set all the issues to "---", and delete the other options,
>> effectively disabling the field.
>
> -1
>
> 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.
Some bugs are specific to version, *BUT* because the bug entry form refers
to this field as "Found in version:", it's getting filled in with versions
by the requestor, without any consideration whether it applies to all or
not.
Version doesn't really apply to tasks - target milestone does, though, are
you thinking of that?.
> Certainly, the version (and OS and platform) fields should be reviewed
> and changed where necessary, but blindly changing /everything/ is a
> mistake.
At the moment, it typically contains bogus data. I want to remove the
bogosity.
It's generally not easy to know immediately which versions something applies
to, so I'd like the often-erroneously set field to go away. Real validated
thoughts on version-specificity can be made in comments.
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 16:30:31 2005