Bugzilla changes

Sebastian Lackner sebastian at fds-team.de
Mon Sep 28 07:59:30 CDT 2015


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
> 




More information about the wine-devel mailing list