| Re: [jdt-dev] Reviewing automated error reports |
With Mars M5 the error reporter sends daily email alerts to interested committers. As discussed above I configured a daily email alert for problems in JDT that have been reported by 5 or more distinct users. I cannot oblige any committer to subscribe to email alerts but I‘ve the hope that one or two of you find the 5 minutes per day to (briefly) review the items that passed the ’noise’ thresholds in the past 24h and decide whether it (now) should be tracked in bugzilla or not. Just to make sure that there is no misunderstanding: this is no statement that these bugs *must* be triaged when a committer reviewed them or moved it to bugzilla. It’s only a way to notify committers about *potential* problems. Once tracked in Bugzilla other users can find it and can comment on it as well or may even sign up to fix it. (FWIW, I agree to Dani’s plaster thinking). Committers can be added / add themselves to existing alerts at [1]. You may also define second level alerts with higher thresholds of, say, 25 reporters (as reminders so to say). I wrote a short guide for WTP how committers can use the error reporter web ui for reviewing problems and move them to bugzilla if they feel they have enough information. FWIW, there is also an option to mute problems or to mark them as log messages (and not bugs). I’ve attached the doc for your reference below. Please do not hesitate to contact me in case you have any questions or suggestions. Thank you Marcel ——— Greetings, I’ve enabled the daily digests for org.eclipse.wst and org.eclipse.jst today. Rob and Victor will now receive emails for every “normal” problem which were reported by at least 5 distinct users. See [1,2] for the exact settings. I promised to provide more information on how to triage problems from the digest emails. Here they go... The basic workflow is as follows. The daily email digest contains a list of links to problems:  Once you click on a link, you’ll get to the problem’s details page. This page contains some general information about the problem like the number of reporters, their contact data if available, as well as the whole stacktrace and all messages and general information about the OS, Eclipse and Java version used.  After the analysis of the stacktrace you should switch to the triage page. The triage page allows you to persist your findings, create a bug from the report or simply muting it for the future:  In case you decide to track this issue further in Bugzilla, press on the report to bugzilla link. This will open a dialog as depicted below:  In that dialog select the right bugzilla component and version, edit the default summary and description if necessary and press OK. The dialog will close now and open a new browser tab that sends you directly to your newly created bug. After that step, there is nothing you have to take care of in the web ui. From time to time the system will synchronize its own state with the state in bugzilla to let users know about the current status but that’s nothing you have to take care of. However, if you need more information (e.g. steps to reproduce) you can make use of one of the above checkboxes (e.g., “this is (maybe) a bug”). If checked, you will get additional boxes in which you can specify additional messages or can request further information from the next reporter etc. On the Eclipse client side, these messages will be presented to the user as notification popups (see [3] for a small video sequence). I won’t go into all details here. I think you have enough information to get started. If you’d like to know more about certain options, or you stumble over some unclear ui elements, or would like to request new features/improvements, please let me know. Please also take a look at the about page [4] and the links there in. They contains references to other resources in the web, manuals etc. and will be updated from time to time. And thank you for your commitment to triage error reports in Eclipse WTP! Marcel |