Bugzilla changes
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: * 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) * 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. * 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. * 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 -- -Austin
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
On Mon, 28 Sep 2015 14:00:37 +0200 Sebastian Lackner <sebastian(a)fds-team.de> wrote:
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.
FYI, links to RESOLVED bugs don't show up by default in the AppDB; the user has to click "Show all bugs" to see them, though that's probably something that should be fixed in the AppDB. -- Rosanne DiMesio <dimesio(a)earthlink.net>
On Mon, Sep 28, 2015 at 7:20 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote:
On Mon, 28 Sep 2015 14:00:37 +0200 Sebastian Lackner <sebastian(a)fds-team.de> wrote:
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.
FYI, links to RESOLVED bugs don't show up by default in the AppDB; the user has to click "Show all bugs" to see them, though that's probably something that should be fixed in the AppDB.
Should be fixed by https://source.winehq.org/git/appdb.git/commitdiff/822908762fa0e5950f626ed27... -- -Austin
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
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(a)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
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 <sebastian(a)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
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. ;)
Make it user-friendly and rename UNCONFIRMED -> INCOMING (or NEW but this will add to the confusion for long time bugzilla users afterwards), and NEW -> CONFIRMED thus eliminating the confusion. P.S. I’m a confused user ;)
On Mon, Sep 28, 2015 at 7:00 AM, Sebastian Lackner <sebastian(a)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
* 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)
There should also be a place for bugs that only show up in wine staging, but can't be considered regressions because the program wouldn't even run in wine. For example, Life is Strange (I've tested episode 1) doesn't work at all in wine. In wine staging, though, it does run, but after a few minutes the performance drops to about 2 FPS. I have no idea if the bug is in wine staging, or it's in wine and you can only notice it when the wine staging patches are applied and the game actually runs. ~Theodore
On Mon, Sep 28, 2015 at 12:02 PM, Theodore Dubois <tblodt(a)icloud.com> wrote:
* 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)
There should also be a place for bugs that only show up in wine staging, but can't be considered regressions because the program wouldn't even run in wine. For example, Life is Strange (I've tested episode 1) doesn't work at all in wine. In wine staging, though, it does run, but after a few minutes the performance drops to about 2 FPS. I have no idea if the bug is in wine staging, or it's in wine and you can only notice it when the wine staging patches are applied and the game actually runs.
~Theodore
File it as a bug in wine. -- -Austin
On 28.09.2015 19:02, Theodore Dubois wrote:
* 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)
There should also be a place for bugs that only show up in wine staging, but can't be considered regressions because the program wouldn't even run in wine. For example, Life is Strange (I've tested episode 1) doesn't work at all in wine. In wine staging, though, it does run, but after a few minutes the performance drops to about 2 FPS. I have no idea if the bug is in wine staging, or it's in wine and you can only notice it when the wine staging patches are applied and the game actually runs.
~Theodore
There is no need to keep them separate, Bugzilla already supports a way to mark bugs as "blocked by a different bug". You would just mention this information, then the Staging patchset can be bisected to find out which other fixes are required, and the bug dependencies can be set accordingly.
participants (6)
-
Austin English -
Benjamin Shadwick -
Rosanne DiMesio -
Sebastian Lackner -
Theodore Dubois -
Wojtek “arab” Arabczyk