[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "version" field in IssueZilla

From: Max Bowsher <maxb_at_ukf.net>
Date: 2005-01-25 16:27:39 CET

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

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

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.


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.