[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-dev
Subject:    Re: "version" field in IssueZilla
From:       Branko Čibej <brane () xbc ! nu>
Date:       2005-01-29 11:57:41
Message-ID: 41FB7A35.6010700 () xbc ! nu
[Download RAW message or body]

kfogel@collab.net wrote:

>"Max Bowsher" <maxb@ukf.net> writes:
>  
>
>>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.
>>
It doesn't have to. Which version a bug was found in is an important 
piece of information.

>> 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.
>>    
>>
Ah, but here's where I don't agree. Yes, most of the time you'll fix a 
bug on the trunk, and possibly merge the fix to the release branch. But 
it's concievable that a bug that existed in some version had been fixed 
for some platforms but not for others, or that it only existed on one 
platform. In that case, you suually have to reproduce with the 
originally reported version on the same platform. You can only me sure 
you fixed a bug  once you know what caused it,

Which, by the way, shows that you can't treat the "version" and 
"platform" entries differently.

>>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.
>>    
>>
>
>Well put.
>
>Personally, I can't come up with a policy useful enough to justify the
>overhead of having the field.  But maybe Brane can?  (hint, hint)
>  
>

Sure. Version = "found in version", OS = "found on OS", platform = 
"found on platform" -- always. "version" never means "to be fixed in 
version", or anything like that -- that's why we have a target milestone 
field, if such a target is important.

-- Brane


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

[prev in list] [next in list] [prev in thread] [next in thread]