Community
Participate
Working Groups
The "Send to Bugzilla" screen which comes up while reporting the bug to Bugzilla can have the "Version" field correctly pre-filled based on the eclipse-build-id present in the error report. Also, the "Hardware" fields on Bugzilla can be updated by tool while creating the bug report based on the operating system details from error report.
(In reply to Noopur Gupta from comment #0) > The "Send to Bugzilla" screen which comes up while reporting the bug to > Bugzilla can have the "Version" field correctly pre-filled based on the > eclipse-build-id present in the error report. Just adding a few assumptions. This is true for Eclipse Platform, JDT, PDE. Everything after the micro version will be cut off. If no exact match is found, the field has to stay empty. We may send a warning email to admins to indicate that there is a problem in the matching. > Also, the "Hardware" fields on Bugzilla can be updated by tool while > creating the bug report based on the operating system details from error > report. How do you want to deal with problems with many different operating systems? A problem may have hundreds of stack traces. Setting the OS on bug creation might be misleading since new incoming incidents then may have a different OS. Is this acceptable?
(In reply to Marcel Bruch from comment #1) > (In reply to Noopur Gupta from comment #0) > > The "Send to Bugzilla" screen which comes up while reporting the bug to > > Bugzilla can have the "Version" field correctly pre-filled based on the > > eclipse-build-id present in the error report. > > Just adding a few assumptions. > This is true for Eclipse Platform, JDT, PDE. > Everything after the micro version will be cut off. > If no exact match is found, the field has to stay empty. > We may send a warning email to admins to indicate that there is a problem in > the matching. I reported this bug from JDT's perspective. The version field can be updated if exact match is found. Otherwise it can be left with the default value which is being used now. > > Also, the "Hardware" fields on Bugzilla can be updated by tool while > > creating the bug report based on the operating system details from error > > report. > > How do you want to deal with problems with many different operating systems? > A problem may have hundreds of stack traces. Setting the OS on bug creation > might be misleading since new incoming incidents then may have a different > OS. > > Is this acceptable? I think it can be set based on the error report which is used to create the bug. The committers monitoring Bugzilla can update it when they have more information. The other way, where a report actually belongs to a specific OS but is created with ALL in Hardware fields is also misleading sometimes. This will be similar to creating a bug report directly on Bugzilla where the Hardware fields are identified and pre-filled based on the reporter's machine/OS. This was just a suggestion and can be left out if not suitable.
(In reply to Noopur Gupta from comment #2) > This will be similar to creating a bug report directly on Bugzilla where the > Hardware fields are identified and pre-filled based on the reporter's > machine/OS. Small update: I have not implemented the OS or version guessing yet, but some preliminary UI and data aggregations that might be interesting to know about. On the problem detail pages we put a (dynamic) aggregation of which bundles (and version ranges) on which operating system and version the problem occurred. See [2] for a screenshot and [1] for a real life example. Note: it's quite slow yet. We are experimenting with this feature and if ppl like it we'll make this faster. [1] https://dev.eclipse.org/recommenders/committers/confess/#/problems/55ce6b71e4b0f0b83a6dd046/details [2] https://www.eclipse.org/forums/index.php/f/69/
The Eclipse AERI server and components have been decommissioned in 2019, see Bug 551898. Therefore any remaining bugs are now being closed as WONTFIX. If this bug is still relevant, please make a comment and we'll move it to the correct project/component for further investigation. This change was made as part of a bulk change.
