> I dug a bit deeper into Sapphire error reports. My conclusion: Adding more
> open source namespaces wont help much in your (and Nebula’s) case. > > Most reports mentioning Sapphire are from the namespaces > "oracle.eclipse.tools.*" > and "com.liferay.*" Some reports show that Sapphire clients even do not follow > the bundle name to package name conventions. Neither oracle.eclipse.* > nor com.liferay.* seem to be open source namespaces. RedHat is an adopter of Sapphire and Liferay is LGPL (http://www.liferay.com/downloads/liferay-portal/license-ce) > Regarding your popup question: > I sense that asking a user for permission whenever a non-eclipse namespace > was discovered in the trace will quickly be very annoying. My thinking is that you only ask regarding the first two or three segments of the namespace and then you persist the choice. So if we already asked you about oracle.eclipse namespace, you aren’t going to be bugged again regarding this. An average user is unlikely to have that many plugins from varied sources installed for these popups to be a big annoyance. > We only send errors that are logged by eclipse.org / apache.org plugins. > However, > it's likely that com.liferay will log errors that reference Sapphire classes. > Following > your previous arguments, you would be interested in those as well. I am surprised to hear that we don’t report these today. > Here we get into trouble. If we do so, we would need to send every error > report > that mentions at least one Eclipse class to eclipse.org. if we do so, users > will notice > dozens of „an error was logged“ popup appears per day (b/c some 3rd party > plugins > causes trouble) and will conclude that Eclipse is extremely buggy. I disagree with the conclusions you draw in these statements. 1. The identity of the party that logged the error is not a predictor of which party is responsible for the error, as clearly evident by the captured error reports that we have. All you know is where the catch clause was located. 2. Users view Eclipse as a whole, in comparison to other IDE choices. They don’t really care that much that the party that’s causing them grief is a third-party plugin, especially if it’s an essential plugin to get Eclipse to fulfill a given function. > I’m not sure I wanna go down this road. At some point we need to draw a line > between error that are caused by third-party plugins (like Liferay or Oracle) > and > those caused by Eclipse plugins. There is no automated system for making that determination in a reliable manner. We should be erring on the side of capturing more error reports as that’s the best way to ensure that more errors get fixed. > I think those clients (which currently make ~28% of the error reports) > should actually sign-up and subscribe to their error reports - or set up > their own > error collection to review and fix their issues themselves. Think of the user experience if every third-party plugin operated their own error collection system, with notices and approvals and every system operating slightly differently. That’s a pretty good recipe for some unhappy users. Ideally, I’d like to see Eclipse error reporting system opened to third-party plugin builders, so they can register, get notices, the whole bit. Absent that, I’d like to be able to at least manually help Sapphire’s adopters improve their plugins and help them help me to improve Sapphire. Thanks, - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Marcel Bruch Sent: Friday, July 24, 2015 8:27 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code Konstantin, I dug a bit deeper into Sapphire error reports. My conclusion: Adding more open source namespaces wont help much in your (and Nebula’s) case. Most reports mentioning Sapphire are from the namespaces "oracle.eclipse.tools.*" and "com.liferay.*" Some reports show that Sapphire clients even do not follow the bundle name to package name conventions. Neither oracle.eclipse.* nor com.liferay.* seem to be open source namespaces. Regarding your popup question: I sense that asking a user for permission whenever a non-eclipse namespace was discovered in the trace will quickly be very annoying. The next thing to consider: We only send errors that are logged by eclipse.org / apache.org plugins. However, it's likely that com.liferay will log errors that reference Sapphire classes. Following your previous arguments, you would be interested in those as well. Here we get into trouble. If we do so, we would need to send every error report that mentions at least one Eclipse class to eclipse.org. if we do so, users will notice dozens of „an error was logged“ popup appears per day (b/c some 3rd party plugins causes trouble) and will conclude that Eclipse is extremely buggy. I’m not sure I wanna go down this road. At some point we need to draw a line between error that are caused by third-party plugins (like Liferay or Oracle) and those caused by Eclipse plugins. I agree to your previous statement that if we can't make sense of error reports containing third-party traces, we should not collect them. This will certainly lead to a better user experience and is something we should definitely change for SR1. I see that this does not solve your issue with Sapphire clients but in this regard I’m more with Gunnar. I think those clients (which currently make ~28% of the error reports) should actually sign-up and subscribe to their error reports - or set up their own error collection to review and fix their issues themselves. But if we collect them for them, it must be clear to the users that these errors are caused by Liferay, Oracle, Findbugs or whatever third-party plugin. Eclipse should not make the impression of being buggy if third party plugins are behaving badly. Marcel Am 23.07.2015 um 19:23 schrieb Konstantin Komissarchik <konstantin.komissarc...@oracle.com>: A big +1 -----Original Message----- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Max Rydahl Andersen Sent: Thursday, July 23, 2015 5:12 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code On 22 Jul 2015, at 20:37, Marcel Bruch wrote: Konstantin, I assume you understand that user may find stacktraces to contain potentially sensitive data (if not - let’s assume it hypothetically), which options would you propose? I'll repeat what I've suggested in the past: add more to the list of OSS packages, i.e. add org.jboss.*, *.redhat.* and org.spring.* and possible more from the top 10 OSS plugins on marketplace. So at least the OSS collaborators can be contacted and we can help improve ;) /max http://about.me/maxandersen _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Phone: +49-6151-276-7092 Mobile: +49-179-131-7721 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
