Re: Bugzilla changes

[Sebastian Lackner]

On 28.09.2015 16:54, Benjamin Shadwick wrote:
> Wait, "UNCONFIRMED" means confirmed, or do you mean that confirmation is
> not captured as a state between UNCONFIRMED and NEW?

No, the NEW status means confirmed. However, most people do not really make
a difference between UNCONFIRMED and NEW. The more important part was the
description of the process afterwards. ;)
> Is there any accountability to the bug submitter that the submitted patch
> addresses the issue in a satisfactory manner (i.e. a verification step), or
> is that arbitrated behind the scenes as part of the review process, or does
> the bug submitter have no formal voice in the process after submitting?

The status will be changed as soon as patch which is supposed to fix the issue
has been added to Wine Staging. In most cases developers have already confirmed
that the patch works as expected at this point, and no additional testing is
required. (Testing usually happens before the patch is submitted/added anywhere.)

If a bug submitter notices that the bug status does not correctly reflect his
test results, it is highly recommended to report that of course (in the
corresponding bug report, or to a bugzilla admin). It could for example mean that
a proposed patch is not complete, which is a very useful information for the patch
author, or that a proposed fix is no longer necessary.

To simplify the synchronization of the bug status it might also be useful to
automate part of the process, however I would first like to ensure that the way
it is implemented right now (as a RESOLVED-status) is really the final decision.
> On Mon, Sep 28, 2015 at 5:59 AM, Sebastian Lackner 
> wrote:
> > Dmitry just pointed out, that there are no versions yet in the Wine
> > Staging product:
> > https://bugs.winehq.org/show_bug.cgi?id=39353
> >
> > Would also be nice to get this fixed soon. ;) Ancient versions are not
> > really necessary,
> > but at least versions >= 1.7.30 would be nice to have.
> >
> > Currently the oldest bug report on our bugtracker was filed with 1.7.32.
> >
> > On 28.09.2015 14:00, Sebastian Lackner wrote:
> > > On 28.09.2015 08:56, Austin English wrote:
> > > > Howdy all,
> > > >
> > > > As Alexandre mentioned [1], at WineConf we made several decisions to
> > > > modify bugzilla in a few ways. I've now implemented those changes,
> > > > which are outlined below:
> > >
> > > Hi Austin,
> > >
> > > thanks for doing these changes. :)
> > > > - New wine-staging product: This should be used for bugs caused by
> > > >
> > > > patches that are in wine-staging, but that do not occur in
> > > > wine-development (i.e., wine-staging patch regressions)
> > >
> > > As far as I know there were some concerns to call it "wine-staging", and
> > > it was preferred to call it just "staging". Did you use the original name
> > > to avoid ordering problems?
> > > > - New STAGED resolution: This is to differentiate bugs that are FIXED
> > > >
> > > > (in wine-development) from bugs that are not present in wine-staging
> > > > because of one or more patches. The anticipated workflow is:
> > > > UNCONFIRMED > bug confirmed, NEW > patch written and sent to
> > > > wine-patches, if it's accepted, FIXED. If not, and the patch is
> > > > integrated into wine-staging, then the bug is STAGED. When the patch
> > > > is revised and eventually integrated into wine-development, the bug
> > > > should move to FIXED.
> > >
> > > Wasn't the idea to add it as a non-RESOLVED status? I personally do not
> > > care that much about the difference, but we should probably decide before
> > > we use it everywhere. Also it would be nice to have a field to keep track
> > > of the staged patchset, without writing it in a comment. What about an
> > > additional field which is only present when this status is selected?
> > > (similar to the Regression SHA field for example)
> > > > - New NEEDINFO resolution: There's a lot of confusion and different
> > > >
> > > > handling by triagers for what to do with bug reports that are
> > > > incomplete (i.e., leaving it open versus closing invalid). To mitigate
> > > > this, I've added a NEEDINFO resolution. If a bug report lacks needed
> > > > information, set it to this status. Bug that have been open NEEDINFO
> > > > for more than 1 year can be closed.
> > >
> > > Similar to the staging status, why is this a RESOLVED status? Its not
> > > really a final status, so a non-RESOLVED status would make more sense
> >
> > maybe.
> > > > - Renamed UPSTREAM to NOTOURBUG: This is more in line with what other
> > > >
> > > > projects do, and eliminates confusion about the upstream/downstream
> > > > distinction.
> > > >
> > > > Please let me know if there are any questions or ideas for further
> >
> > enhancements.
> > > > [1]
> >
> > https://www.winehq.org/pipermail/wine-devel/2015-September/109392.html
> > > >
> > >
> > > Regards,
> > > Sebastian