http://bugs.winehq.org/show_bug.cgi?id=58597
--- Comment #3 from Stian Low wineryyyyy@gmail.com --- (In reply to Ken Sharp from comment #2)
Bugzilla already has severity ratings: https://bugs.winehq.org/page.cgi?id=fields.html#severity
I don't think linking the bug severity to the AppDB makes any sense
Agreed, linking AppDB per severity or even simply on bug basis is not sufficient. Rather, linking on a per bug comment basis seems more sufficient.
even a major bug can have a workaround and this is only evident in the comments. Any critical or blocker bug potentially affects every application and linking such a bug to every application on the AppDB would be a bad idea.
Agreed. Such critical bugs widely affecting AppDB entries do not need to spawn efforts to seek out all AppDB entries affected. However, when tests fail due to such critical bugs and comments are added regarding the failure, it seems to make sense at that point to link the failures as test results to AppDB to reflect the most recent status/rating.
Test results without Platinum highest ratings should link to newly spawned and/or existing bugs. Similarly many bug comments should link to newly spawned and/or existing AppDB entries.
this is only evident in the comments.
AppDB test results are often partially submitted as bug screenshots, logs, comments, etc but often not reflected in AppDB because it may be too time consuming and partially redundant.
Adding AppDB support for links to Bugzilla user comments may offer a solution to redundancy.
Balancing flexibility with convenience and effectiveness is a challenge.
For flexibility, AppDB maintainers may want to submit test results on behalf of various Bugzilla users and comments.
A better solution may be encouraging Bugzilla users to submit test results on their own behalf which may require adding conveniences to Bugzilla to link comments to AppDB test results.
How may AppDB test result linking be convenient for Bugzilla commenters? Again flexibility vs convenience is a challenge.
AppDB linking per bug comment may be necessary to support linking comments to apps other than the app reported by a bug. For example, games other than the game for which a bug is reported may be tested to troubleshoot different behaviors. In this case, Bugzilla comments need additional fields that support selecting from test results listings from AppDB.
Bugzilla may need to query AppDB for test results listing to pick from in a similar way that AppDB was changed to query Bugzilla for bug links and Wine versions.
However, doing so partially defeats the purpose of the AppDB and Bugzilla DB separation recently merged because it adds back more traffic dependence back between the apps: https://gitlab.winehq.org/winehq/appdb/-/merge_requests/13
Unlike AppDB which queries Bugzilla only for a few HTML pages, Bugzilla may query AppDB on a per comment basis. At that point, consolidation between the AppDB and Bugzilla seems in order.
Separate user accounts between Bugzilla and AppDB is already a redundancy that may discourage AppDB engagement.
Perhaps Gitlab which is under consideration to replace Bugzilla offers a solution to redundancies.
Test results are related to continuous integration which Gitlab offers supporting features which may be leveragable to provide a more convenient solution for connecting test results to bugs and comments. Then AppDB could behave more as a simple front end similar to: https://www.protondb.com/
This however may introduce yet another neglected inconvenience with the overhead of having to maintain comment test result accuracy. For instance, a test result for an app may be submitted as garbage against said critical bug but not retested after the critical bug is resolve so AppDB reflects a garbage despite a fix. Ideally the tester would retest to override the previous but that may not happen.
This inaccuracy however is still a problem with AppDB regardless which partially prompted this bug report.