Hi Caolan,

> There are 470, four hundred and seventy! "versions" listed by issuezilla
> for e.g. tools.

way too much, agreed. The better solution would be if Version was a
free-text field, but alas ...

> Can we cull these to at least remove all the milestones < current - 5,
> and consider dropping the release candidates and the 1.0.X releases.

What would we do then with the issues which currently have one of those
versions set? We cannot simply remove the versions, this would violate
the data integrity. We would have to reset this field for the affected
issues.

Then, reset to which value? Issue handling guidelines say one shouldn't
touch the version field, it should contain the version of *first*
occurance. If we would want to re-version existing (open) issues to a
newer milestone where they still appear - this guideline would need to
be discussed first. Also, who will do the work to verify whether those
issues really still happen? Or do we silently assume they do?

If we re-version the existing (open) issues to something else
("indetermined" or whatever), this would be a loss of imporant
information. Not a good idea, in general. We would at least need some
script which re-adds this information to a comment. Even then, there
should be a broader consensus that this is the way to go, since the
information is more difficult to find in the comments, as opposed the
dedicated Version field.


Alternatively, let convince collab.net to change this to a free-text.
Ah, what am I saying here? Forget it, just kidding.

> Who's the contact for the versions, collabnet ?

There's a few people who have the power to administrate this aspect of
IssueZilla. So once there's an agreement, this can easily be done
without collab.net. However, the agreement is the difficult part.

Do you have some numbers about issues on older milestones? What I would
be interested in is
- About what milestones do we actually talk, more precise?
- How many unresolved issues exist which are versioned to one of those
  milestones?

Without knowing this, we can, IMO, not decide what to do.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer         [EMAIL PROTECTED] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to