Bugzilla changes

[Benjamin Shadwick]

Wait, "UNCONFIRMED" means confirmed, or do you mean that confirmation is
not captured as a state between UNCONFIRMED and NEW?

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?

On Mon, Sep 28, 2015 at 5:59 AM, Sebastian Lackner <sebastian at fds-team.de>
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
> >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20150928/7f9633e7/attachment-0001.html>