Discussion of bug versions

[Jeremy White]

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?

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).

Obviously, it seems that it would be really nice if, when we did that,
it was a lot easier to find 1.1.5...

Cheers,

Jeremy

[Vitaliy Margolen]

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.
> 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.

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.

Vitaliy

[James Hawkins]

On Sun, Sep 28, 2008 at 4:43 PM, Vitaliy Margolen
 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.
> > 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.

The version field should be 'the earliest known version in which the
bug exists.'  If they're keeping up with git, the fact that the bug is
still open and not resolved means the bug still exists in git.  The
use of the version field is not necessary for this functionality.

[Vitaliy Margolen]

James Hawkins wrote:
> On Sun, Sep 28, 2008 at 4:43 PM, Vitaliy Margolen
>  wrote:
> > Jeremy White wrote:
> > > 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.
>
> The version field should be 'the earliest known version in which the
> bug exists.'  If they're keeping up with git, the fact that the bug is
> still open and not resolved means the bug still exists in git.  The
> use of the version field is not necessary for this functionality.

The thing is, that version does not exist yet. And the prior version doesn't
have said bug.

Vitaliy

[Austin English]

On Sun, Sep 28, 2008 at 4:43 PM, Vitaliy Margolen
 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

[Darragh Bailey]

On Mon, Sep 29, 2008 at 12:53:17PM -0500, Austin English wrote:
> On Sun, Sep 28, 2008 at 4:43 PM, Vitaliy Margolen
>  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?

If that is bothering people so much, perhaps a patch to bugzilla to be
able to change the order versions are displayed in would be more 
appropriate than removing old versions.

[Hin-Tak Leung]

--- On Sun, 28/9/08, Jeremy White  wrote:
<snipped>
> 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 am not sure I agree with this, but obviously it is up to the rest of
wine-devel. The pros of having CVS/GIT as version choice is that it
encourages people to try out the latest and greatest from git  - and I do;
- in wine's case, since wine has a release cyle of 3 weeks, it is less of
an issue - other software with a release cycle of 9 months benefits
greatly from people reporting bugs against CVS/GIT. (and people reporting
bugs against a release are often asked to try out CVS/GIT).

The con is actually less trouble than you think - if somebody reports a bug against CVS/GIT, it would be reasonable to assume that the report date is within a day or two compared to the git clone/rebase-origin date.
Other use of GIT (the kernel) report-date is not very indicative of
the state of the tree, but since only one person has commit-rights in wine,
the report-date is a good indicator of a specific few commits.

[James McKenzie]

Hin-Tak Leung wrote:
> --- On Sun, 28/9/08, Jeremy White  wrote:
>
> <snipped>
>
> The con is actually less trouble than you think - if somebody reports
> a bug against CVS/GIT, it would be reasonable to assume that the
> report date is within a day or two compared to the git
> clone/rebase-origin date. Other use of GIT (the kernel) report-date is
> not very indicative of the state of the tree, but since only one
> person has commit-rights in wine, the report-date is a good indicator
> of a specific few commits.

There is a problem with using CVS/GIT and that is we are ASSUMING that
the version used is only a couple of days old, it could be as much as a
week old.  I prefer reports against valid and released versions as
problems found with a commit may be fixed with another corrective commit
(this has happened several times in the last year.)

+1 to NO CVS/GIT and NO CVS/GIT reporting in Bugzilla, unless we are
going to do build numbers based upon the day of build.

James McKenzie
>

[wineappdb]

On Sun, 28 Sep 2008 16:46:17 -0700
James McKenzie  wrote:
> Hin-Tak Leung wrote:
> > --- On Sun, 28/9/08, Jeremy White  wrote:
> >
> > <snipped>
> >
> > The con is actually less trouble than you think - if somebody reports
> > a bug against CVS/GIT, it would be reasonable to assume that the
> > report date is within a day or two compared to the git
> > clone/rebase-origin date. Other use of GIT (the kernel) report-date is
> > not very indicative of the state of the tree, but since only one
> > person has commit-rights in wine, the report-date is a good indicator
> > of a specific few commits.
>
> There is a problem with using CVS/GIT and that is we are ASSUMING that
> the version used is only a couple of days old, it could be as much as a
> week old.  I prefer reports against valid and released versions as
> problems found with a commit may be fixed with another corrective commit
> (this has happened several times in the last year.)
>
> +1 to NO CVS/GIT and NO CVS/GIT reporting in Bugzilla, unless we are
> going to do build numbers based upon the day of build.
>
> James McKenzie
> >

Why not offer version + (GIT) e.g "1.1.5 GIT" or e.g "1.1.5+" ?
And to pick it offer a combo box "Release" or "Git" then you pick your wine version.

[Lei Zhang]

On Sun, Sep 28, 2008 at 6:35 PM, wineappdb  wrote:
> Why not offer version + (GIT) e.g "1.1.5 GIT" or e.g "1.1.5+" ?
> And to pick it offer a combo box "Release" or "Git" then you pick your wine version.

That'll double the number of Wine versions, and make searching much
harder. Just think of 1.1.5 as [1.1.5 - 1.1.6).

[Markus Hitter]

While on the topic, please remove Mac OS up to 10.3 from the list of  
operating systems. Mac OS X 10.4.x was the first publicly available  
Macintosh OS running on Intel processors, so there won't ever be  
anybody running Wine on e.g. MacOS 9.

MarKus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/