Discussion of bug versions

[Austin English]

On Sun, Sep 28, 2008 at 4:43 PM, Vitaliy Margolen
<wine-devel at kievinfo.com> wrote:
> Jeremy White wrote:
>> We discussed bugzilla versions at Wineconf, re:
>>
>> http://bugs.winehq.org/show_bug.cgi?id=12728
>>
>> There were several points of consensus.  First, it would be helpful
>> if we could reduce the number of versions visible in the drop down
>> box when entering a new bug.  That would seem to require
>> a bugzilla code change, though.  Anyone know of an easy way to
>> accomplish this?
> AFAIK it's already done in automated fashion in AppDB. Can take code from there.

+1 I HATE having to scroll for 15 seconds just to get to the current
version. The problem is, how can we remove all those old versions
while not deleting the bugs/flooding wine-bugs mailing list? Can we
disable global e-mail while renaming them? Can we make a new 'version'
that is "old", "pre-0.9.50", etc.? And move all those there?

>> Second, we'd like new bug reporters to not be able to use
>> the 'CVS/GIT' version choice, but to instead be encouraged to
>> report the current version.  (wine --version reports something
>> that is easy to match up to the choices).
> I'm strongly against this. There are number of bug reporters who use git and
> update it every day. What should they use for their bug reports? IMHO their
> reports are much more valuable and allows developers to catch bugs early on
> before they get into the release.

+1 CVS/GIT only causes more confusion, especially if the bug isn't
fixed quickly.

> Otherwise it will take at least 2 releases to correct each introduced
> regression. For some regressions it takes just 2 versions for users to
> notice it and identify the patch in question.

I disagree. If the developers are reading wine-bugs as they should be
(or are watching their CC'ed bugs, at the very least), they'll be
aware of the regression they caused. Just because it's not yet in a
reported version doesn't mean they won't fix it. Ideally, the bug will
be fixed before it ever hits a released version. Removing CVS/GIT,
however, will reduce confusion. And if the bug isn't reported until 2
versions after release, CVS/GIT would be irrelevant anyway, as they
wouldn't be using it.

Assuming we do this, what are we going to rename the CVS/GIT bugs to?

-Austin