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 <http://eclipse.org/> / apache.org <http://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 <http://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
