Bugzilla – Full Text Bug Listing
| Summary: | provide a flexible bug reporting facility | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Mik Kersten <mik.kersten> | ||||||||||||
| Component: | Mylyn | Assignee: | Steffen Pingel <steffen.pingel> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||
| Severity: | enhancement | ||||||||||||||
| Priority: | P3 | CC: | a.gurov, contact, eclipse, hbershadskaya, mknauer, mober.at+eclipse, overholt, shawn.minto, tomasz.zarna, wmitsuda | ||||||||||||
| Version: | unspecified | Keywords: | noteworthy, plan | ||||||||||||
| Target Milestone: | 3.2 | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Windows Vista | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Bug Depends on: | 150278, 183606, 199706, 277401 | ||||||||||||||
| Bug Blocks: | 229495 | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Mik Kersten
*** Bug 211141 has been marked as a duplicate of this bug. *** Hi, This item relates to my tasks. So, I think I could share my opinion about the problem here. All previous versions of the Subversive plug-in, which were distributed not from Eclipse.org, contain their own bug reporting system. Now the tracker of our project has migrated to Eclipse.org Bugzilla and we perform some work in order to substitute Subversive bug and tip reporting system with the Mylyn based one. 1) So, Mik is absolutely right about the main requirement for this feature: user should not interact with any additional UI if it could be omitted due to some automation. For example, in the Subversive project we have our own error handling mechanism which allows to make decision what errors should be treated as "normal" (network failures etc.) and what exceptions shoud be reported as bugs. So, we known all minimally required information for posting the bug report: 1) what repository is required 2) what project should be used for this report 3) product environment and configuration, versions etc. Also when user select our menus to send bug or tip report to our product we also can use the same information automatically. Practically, concrete product will detect if the issue should be reported, then it will configure RepositoryTaskData (in the Mylyn API terms), then it will ask Mylyn to open the bug report editor for preconfigured task data. So, now user only should press "Submit" button and it could, optionally, specify additional information in the description field. 2) Also I think "Report as Bug facility in the Error Log view" is not a rudimentary one, but it could be greatly improved. Why is not a rudimentary one? For example, initially in the Subversive we have two reporting mechanisms - first serves all plug-in logic which represents most of the plug-in features, second listens for any logged errors and if it corresponds to some conditions this mechanism automatically asks user to report the issue. I.e. the second mechanism is very useful in order to detect UI issues which are catched by UI thread. After several development iterations when our plug-in reached more stable state we switched off the error log listener in order to reduce IDE load and prevent false reports when unrelated exceptions are contained in its stack trace information which will cause reporting issue to our tracker. Now, using the "Report as Bug" facility user may post the related issue from the Error Log view to our tracker nevertheless automated listener is disabled. How it could be improved? Mylyn could provide API which allows to ask loaded extension points about the logged IStatus object if this status should be reported for the concrete product or not. If the status declined by all products we have 2 variants: - disable the "Report as Bug" facility for the status - propose user to enter all required information manually (as it works now) If only one extension point accepted this status, then do as described in the point 1). If several extension points accepted the status then we again have two choices: - send report to all products - ask user to which product really relates the issue. 3) Another side of the problem is that not all products could have trackers connected to Mylyn due to different reasons: - project has no tracker - project tracker has no connector for the Mylyn - project does not allow reporting issues from not authorized sources etc. These projects could work with mailing lists (as earlier version of Subversive, for example). So, it would be great if Mylyn also could allow mail reporting for these projects. AFAIK SUN's Mail API library license is compatible with the EPL and it allows to implement mail reporter relatively easy. What do you think about it? Thank you for adding your requirements and your input Alexander. It's great to hear that the Subversive project is interested in leveraging Mylyn for bug submission. I think it would be a great benefit to the user and Eclipse community to have a unified bug reporting facility for Eclipse projects that is easier to use than what Mylyn currently offers and more extensible. I discussed the API with Mik and I'll try to summarize the architecture we came up with.
The error handling code will take IStatus objects as inputs that may be provided from different sources:
* through "Report as Bug from the" error log
* by invoking org.eclipse.mylyn.monitor.core.StatusHandler.fail(IStatus)
* by an implementation of ILogListener that listens to platform logging events
These status objects are passed to classes that implement AbstractErrorReporter:
class AbstractErrorReporter {
public static int PRIORITY_NONE = -1;
public int getPriority(IStatus status);
public void handle(IStatus status);
}
Implementations of the class are discovered through a new extension point provided by Mylyn. The handle() method of the error reporter that returns the highest priority for a status object will be invoked. If all reporters return PRIORITY_NONE nothing happens. If two or more reporters return the same priority that is higher than any other priority returned the user is prompted to select an error reporter.
The error reporter determines how to handle the error, e.g. send it via email, post it to a news group etc.
Mylyn provides a default TaskErrorReporter that uses the task editor to report bugs. To minimize the amount of input required by the user Mylyn provides an extension point to specify properties for populating the editor (bug 150278). The extension point maps plug-in ids to a repository and to a list of semi-colon separated attributes:
<extension point="org.eclipse.mylyn.tasks.pluginRepositoryMappings">
<pluginRepositoryMapping
pluginIdPrefix="org.eclipse.mylyn.tasks"
repositoryUrl="https://bugs.eclipse.org"
repositoryKind="bugzilla"
attributes="product=Mylyn;component=Tasks"/>
</extension>
The TaskErrorReporter will use the plug-in id of a status object to determine the best mapping. It will collect attributes by iterating over the list of extensions that specify a matching prefix. In the case of an error in org.eclipse.mylyn.tasks.ui it might find the following:
org.eclipse.mylyn.tasks.ui => component=Tasks
org.eclipse.mylyn => product=Mylyn
org.eclipse => repository=https://bugs.eclipse.org
If enough information is available to initialize a TaskData object a pre-populated editor will be opened that will only prompt the user to provide additional details in the description. If the information collected from the plugRepositoryMapping extensions was not sufficient to initialize a TaskData object the user will be prompted to select the repository/product etc.
The current plan is to implementing the outlined architecture as a first step for Mylyn 2.3 and then iterate over the API and extension points in Mylyn 3.0 (Ganymede).
Created attachment 88104 [details]
picture of the proposed architecture
Alexander, see below for more specific responses to your suggestions and how they were accounted for into the proposed architecture. (In reply to comment #2) > So, we known all minimally required information for posting the bug > report: > 1) what repository is required > 2) what project should be used for this report > 3) product environment and configuration, versions It should be possible to specify these properties through the pluginRepositoryMappings extension point or get them from the platform. > Practically, concrete product will detect if the issue should be reported, then > it will configure RepositoryTaskData (in the Mylyn API terms), then it will ask > Mylyn to open the bug report editor for preconfigured task data. So, now user > only should press "Submit" button and it could, optionally, specify additional > information in the description field. Yes, in most cases it should be possible to determine the required information to pre-populate the task editor. The user certainly needs to have an option to open the editor to review the data that is transmitted. > For example, initially in the Subversive we have two reporting mechanisms - > first serves all plug-in logic which represents most of the plug-in features, > second listens for any logged errors and if it corresponds to some conditions > this mechanism automatically asks user to report the issue. I.e. the second > mechanism is very useful in order to detect UI issues which are catched by UI > thread. After several development iterations when our plug-in reached more > stable state we switched off the error log listener in order to reduce IDE load > and prevent false reports when unrelated exceptions are contained in its stack > trace information which will cause reporting issue to our tracker. [...] > Mylyn could provide API which allows to ask loaded extension points about the > logged IStatus object if this status should be reported for the concrete product > or not. Subversive could feed these error to Mylyn by registering an ILogListener that invokes the Mylyn StatusHandler. I am not sure if Mylyn will provide a default ILogListener for reporting bugs. The current mechanism that requires the user to explicitly report the bug from the error log is very unintrusive and will only require very few clicks with proposed architecture. > If the status declined by all products we have 2 variants: > - disable the "Report as Bug" facility for the status I think it could be confusing to the user if the menu item is enabled on some items but not on others therefore I would rather always allow it. > - propose user to enter all required information manually (as it works now) > If only one extension point accepted this status, then do as described in the > point 1). > If several extension points accepted the status then we again have two choices: > - send report to all products > - ask user to which product really relates the issue. In terms of the proposed API that would mean that multiple pluginRepositoryMappings specify conflicting attributes. In that case the selection in the task editor would point to whichever extension is read last. > 3) > Another side of the problem is that not all products could have trackers > connected to Mylyn due to different reasons: > - project has no tracker > - project tracker has no connector for the Mylyn > - project does not allow reporting issues from not authorized sources > etc. > These projects could work with mailing lists (as earlier version of Subversive, > for example). So, it would be great if Mylyn also could allow mail reporting for > these projects. AFAIK SUN's Mail API library license is compatible with the EPL > and it allows to implement mail reporter relatively easy. This would be possible by extending AbstractErrorReporter. It is currently out of the scope of the Mylyn project to provide error reporting through Email but the proposed API would enable this through the an extension point for 3rd parties to implement. Steffen, I see you are replacing all old StatusHandler calls with something like this: StatusHandler.fail(new Status(IStatus.ERROR, JiraUiPlugin.PLUGIN_ID, "Error updating attributes", e)); wouldn't it be better to move redundant creation of the status object into the StatusHandler.fail() method? So call can be shortened like this: StatusHandler.fail(IStatus.ERROR, JiraUiPlugin.PLUGIN_ID, "Error updating attributes", e); I prefer the current implementation that limits the API that needs to be maintained for Mylyn to a single call rather than creating a fail() and log() method for each of the numerous constructors of the Status class. That still would be one method, taking optional parameters same way as Status class does. The important point that it would look less verbose in the caller's code, which I believe is more important for the clean api. Helen, I have replaced the deprecated calls to the StatusHandler in the XPlanner code. That also caused the imports to get organized in some files (this is enabled by default on save now). Please review if the changes I made are okay. Steffen, thanks for letting me know. The changes look good from what I could see. thanks (In reply to comment #5) > It should be possible to specify these properties through the > pluginRepositoryMappings extension point or get them from the platform. ..... > Yes, in most cases it should be possible to determine the required information > to pre-populate the task editor. The user certainly needs to have an option to > open the editor to review the data that is transmitted. Extension point looks very good. > Subversive could feed these error to Mylyn by registering an ILogListener that > invokes the Mylyn StatusHandler. I am not sure if Mylyn will provide a default > ILogListener for reporting bugs. The current mechanism that requires the user > to explicitly report the bug from the error log is very unintrusive and will > only require very few clicks with proposed architecture. Yes, definitely. I mean that installing ILogListener is not a good idea at all. Instead user can select "Report as bug" action (which is added to log by Mylyn) in the pop-up menu and extension point proposed in your architecture vision will provide all required information in order to pre-populate task editor. So, I hope there are no plans to remove such menu item? > I think it could be confusing to the user if the menu item is enabled on some > items but not on others therefore I would rather always allow it. I agree. > pluginRepositoryMappings specify conflicting attributes. In that case the > selection in the task editor would point to whichever extension is read last. But may be the situation is the reason to show a list of projects filtered by "pluginRepositoryMappings" to which a report can be sent? After user selects one of products editor can be pre-populated by corresponding "pluginRepositoryMappings". > This would be possible by extending AbstractErrorReporter. It is currently out > of the scope of the Mylyn project to provide error reporting through Email but > the proposed API would enable this through the an extension point for 3rd > parties to implement. Ok. And few more questions... 1) Now we include into generated report information which cannot be specified by proposed extension point because it can be changed at run-time. The information are: - id of used SVN connector - filtered JVM properties (allow to automatically detect many issues related to environment). So, is it possible to introduce some interface related to specified extension point which will provide additional dynamically generated information in order to include it into the generated report? 2) The same relates to sending a tips for improvement (dynamically generated information). So, is it possible to access the same extension point in order to ask the information even if user simply wants to report enhancement (i.e. no stack traces available, but product is selected manually)? (In reply to comment #11) > Yes, definitely. I mean that installing ILogListener is not a good idea at all. > Instead user can select "Report as bug" action (which is added to log by Mylyn) > in the pop-up menu and extension point proposed in your architecture vision will > provide all required information in order to pre-populate task editor. So, I > hope there are no plans to remove such menu item? No, we'll keep the current action but make it extensible through the described extension point. > > pluginRepositoryMappings specify conflicting attributes. In that case the > > selection in the task editor would point to whichever extension is read last. > But may be the situation is the reason to show a list of projects filtered by > "pluginRepositoryMappings" to which a report can be sent? After user selects one > of products editor can be pre-populated by corresponding > "pluginRepositoryMappings". Yes, that's a good idea. I am not sure if we'll be able to implement this in the first pass but it's certainly an enhancement that could be added later. > 1) > Now we include into generated report information which cannot be specified by > proposed extension point because it can be changed at run-time. The information > are: > - id of used SVN connector > - filtered JVM properties (allow to automatically detect many issues related to > environment). > So, is it possible to introduce some interface related to specified extension > point which will provide additional dynamically generated information in order > to include it into the generated report? Yes, it could be too difficult to specify all this information as text in an extension particularly if part of it is generated from configuration details that depend on the runtime environment. We could add an extension point that invokes a class to add additional text to the report, e.g. ITaskReportContributor { String getErrorText(IStatus status) /** see below */ String getFeatureText(IStatus status) } > The same relates to sending a tips for improvement (dynamically generated > information). So, is it possible to access the same extension point in order to > ask the information even if user simply wants to report enhancement (i.e. no > stack traces available, but product is selected manually)? Great idea, we haven't thought much about how to pre-populate bugs for feature requests: bug 183606. How about using the same extension point as (1)? (In reply to comment #12) > ... How about using the same extension point as (1)? I think it will be good. So... we await for availability of this great extension point. :) By the way, is this facility been proven on connectors other then bugzilla? It would be nice to verify how this API works with other connectors. For instance, there are several projects integrating with Mylyn that are not using Bugzilla as their issue trackers. Hello All, We have requests about removing of redundant menu items in Help->Subversive->Send ... but solving of this issue depends on existance of API which is discussed here. Unfortunately I can't find in the Mylyn release schedule when these APIs will be available for integrators. So, could anybody say is there any progress on this task and when can we try this feature? Alexander: the bug to track general progress on is bug 227660. I'll lest Steffen reply with an ETA for the API addition in question (we are currently focused on changes of existing APIs, and will move to additions after those are completed). Sorry for the slow progress on this Alexander. Refactoring the current Mylyn APIs turned out to be more extensive than expected so I haven't had a chance to finalize the error reporting API. We'll take a pass through the remaining priorities for Mylyn 3.0 early next week and should be able to give you an estimate then. Hello Mik, Steffen, Thank you very much for quick and informative reply. *sigh* need to defer finalizing the API to 3.1. The extension points are in org.eclipse.mylyn.tasks.bugs internal and the API is provisional. I still expect changes to the abstract classes that provide details about errors once the UI for the bug reporting is streamlined. Alexander, it is probably best to keep Subversive's current approach for bug reporting that invokes the Mylyn tasks API (or internals) directly. Please let me know if you need any help porting the existing Subversive bug reporting to the Mylyn 3.0 APIs. Would anybody want to give an update about this feature on the next EAC call, Aug 14? I'd be interested in exploring possibilities how Eclipse components (Galileo) could adopt this. http://wiki.eclipse.org/Architecture_Council/Minutes_August_14_2008 Yup, I would be happy to do that. It would be great to have Galileo components using this. In terms of rollout, Mylyn could update the Java package accordingly (we maintain it) and then encourage other package maintainers to do the same. Steffen: could you post a short summary of the status of the API? The API allows to specify mappings from plug-in ids to bug repositories through an extension point. If a bug is reported from the error log and a matching mapping is found a task editor for this repository is opened. If no match is found the user is prompted to select a repository. Additionally clients may provide an implementation of AbstractTaskContributor to specify properties for the created tasks based on an IStatus object that is created from the error log entry. This includes setting any of the attributes in the attribute section such as the version or component or adding content to the description. The extension point and API is provisional and I still expect changes for the 3.1 release. Bug 205196 has further discussion about improving the integrated bug reporting for Eclipse distributions. Martin, please feel free to add your ideas or requirements to any of these bugs. Hello, Steffen. I have a question about taskContributors extension point and implementing AbstractTaskContributor. Firstly, which tag should be used to specify the implementation of AbstractTaskContributor? I've tried <taskContributor class = "org...."/> but is does not work. Sorry, if it's written somewhere, but I can't find it. And the second point is what should be put in the map as keys and values for getAttributes() method. I logically thought that these are the atribute names and values from the editor. Tried to return a map containing one entity <"priority", "p1">... But I can't even test it cause I can't make the task contributor to be launched. Sorry, if this is documented somewhere and I simply was to lasy to spend more time for searching. Hope to get the answer ASAP. Best regards, Alexei Goncharov. (Subversive Team) Oh, sorry. I've just updated Mylyn to 3.0.1 and the scheme is found. The implementation is launched. And so where can I find valid keys and values for attributes to return map? I've tried:
public Map<String, String> getAttributes(IStatus arg0) {
Map<String, String> map = new HashMap<String, String>();
map.put(BugzillaAttribute.BUG_SEVERITY.getKey(), "enhancement");
return map;
}
Didn't help:(...
Alexei: Fyi, Steffen will be back from vacation next week and should be able to answer your question then. Thanks for info, Mik. Steffen, any comments? Sorry for the slow respone Alexei. The only attributes that are currently supported by getAttributes() are defined in IRepositoryConstants: component, description and product. Other attributes that are returned by getAttributes() will be ignored. I will take a look at the current implementation as part of the Mylyn 3.1 release cycle and extend it to support other task attributes as well. Not that severity is currently not part of Mylyn's common task schema but we should consider adding it to support your use-case. Thanks, Steffen. Due to other unexpected priorities I'll have to push this of to the next milestone. Created attachment 136117 [details]
support wizard - first page
Created attachment 136118 [details]
support wizard - second page
Steffen, this hasn't been backported to 3.3 yet, correct? The o.e.m.bugzilla.ide plugin.xml has errors for me. No, not yet. I have that planned for Wednesday before the Galileo drop. The current release that is available from the weekly site now has a new extension point org.eclipse.mylyn.tasks.bugs.support which replaces the previous pluginRepositoryMappings extension point. Bug 150278 and the org.eclipse.mylyn.bugzilla.ide plug-in have examples how to use the extension point. Priority, severity and version can now be modified through a taskContributors extension. when a task is created from the error log (bug 199706) and a corresponding productRepository mapping specifies a featureId the default contributor will pre-select the version in the task editor based on the installed version. Please don't hesitate to file additional bugs if you need further extensibility. Created attachment 137379 [details]
bug banner for wizard
Steffen: Would this be a better banner image?
Created attachment 137381 [details]
bug icon
This could work well for the Error Log contribution?
Yes, these icons look great. Can you integrate them? Do you have ideas for the "Rpeort Bug or Enhancement" icon? The blue bug over the blue repository doesn't have that much contrast and makes it hard to pick out what the icon stands for. We could use the same icon as attached on this bug? If you could give that and the banner a try I can iterate on the design after you show me what it looks like. (In reply to comment #37) > The current release that is available from the weekly site now has a new > extension point org.eclipse.mylyn.tasks.bugs.support which replaces the > previous pluginRepositoryMappings extension point. Here is a viewCVS link to the mentioned examples for the new extension point: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mylyn/org.eclipse.mylyn.bugzilla.ide/plugin.xml?revision=1.27&root=Tools_Project&view=markup In order to be present in the JEE package, I'd like to request adding TM/RSE as a provider. Here is the code that I figure should be in there: <product id="org.eclipse.rse" providerId="org.eclipse" featureId="org.eclipse.rse.core" /> <mapping namespace="org.eclipse.rse" productId="org.eclipse.rse"> <property name="product" value="Target Management"/> <property name="component" value="RSE"/> </mapping> <mapping namespace="org.eclipse.tm.terminal" productId="org.eclipse.rse"> <property name="component" value="Terminal"/> </mapping> How should I proceed? Just put this into my plugins, or file a separate bug, or can you pick it up from this comment? Martin: We shied away from doing the JEE package for Galileo as per David William's suggestion at the F2F Architecture Council meeting at EclipseCon. So we haven't considered any mappings for that package yet and only did the Java package which we're responsible for. Would you like to explore adding the TM/RSE anyway? My concern is that you would end up with too many bugs that people meant to report for WTP. Fyi, we've been wondering the same thing regarding listing Mylyn in the JEE package, which is why we ended up leaning to waiting for the next release cycle to do all the packages. But it's certainly open for debate, and it's not that much work to add the mappings. Martin, you should be able to add the extension to one of your plug-ins without introducing a dependency on Mylyn. Let me know if you run into any problems. Mik, I have committed the icons. For the Report Bug or Enhancement action we could also try a bug-only icon without overlaying the new task icon. (In reply to comment #43) > Martin: We shied away from doing the JEE package for Galileo as per David > William's suggestion at the F2F Architecture Council meeting at EclipseCon. Ok, I see... Guess I was confused because I just tried out jee RC1 and saw many support providers defined and usable, so I wanted to be part of the party. My guess is that avoiding rogue bugs is all a matter of having a "good" selection of support providers. If JDT, WTP, RSE are the only providers then people may probably file DTP bugs against RSE... but if we'd manage to get all the major areas covered with few providers, chances are not so bad to get good bug reports. I find that having the stack trace duplicate detection only optional and kinda hidden in the UI is a larger risk of getting lots of dupes, but then you guys in Mylyn have probably much more experience with a high volume of bugs than I do. (In reply to comment #45) > I find that having the stack trace duplicate detection only optional and kinda > hidden in the UI is a larger risk of getting lots of dupes, but then you guys in > Mylyn have probably much more experience with a high volume of bugs than I do. I agree that we need to address that and incorporate better duplicate detection in the workflow. We have some ideas but won't be able to get that done in time for Galileo. |