Bugzilla changes

[Austin English]

On Mon, Sep 28, 2015 at 7:00 AM, Sebastian Lackner
<sebastian at fds-team.de> 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?

Yes, and consistency.

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

I wasn't aware that distinction was made, but I think that makes
sense, I've changed NEEDINFO / STAGED to be statuses rather than
resolutions.

I've also added a 'Staged patchset' field to Bugzilla.

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

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



-- 
-Austin