> is opening and extending automated error reporting to non-eclipse.org plugins, > e.g. to member companies, worth these efforts? In my opinion, it’s the only way to achieve the goals you set out to achieve at the beginning of this project. Users view Eclipse as a whole that encompasses third-party plugins and we need to act accordingly to remain competitive. Thanks, - Konstantin From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Marcel Bruch
Sent: Saturday, July 25, 2015 1:08 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Error reporter and third-party code I'll try to summarize the discussion up to the current point.
The error reporting currently collects errors logged by eclipse plugins, i.e., the plugin-id of the log message needs start with org.eclipse. Log messages logged by 3rd parties (e.g., oracle.tools) are ignored (some exceptions here, e.g. for logging libs).
In stacktraces, class names that do not stem from org.eclipse are anonymized by default (some exceptions here, e.g. for logging libs).
We initially started from the question whether 3rd party class names should be anonymized in general. In the meantime we are discussing whether we should open the error reporting to 3rd parties out there to allow them to get notified about problems in their code. If we do so (just hypothetically), there are a few more things to consider. 3rd parties would get access to confidential data. Then these parties would certainly need to sign some kind of NDA. We currently run the error reporting on a small VM. If the system should collect error reports for every plugin out there, this will need better hardware resources, more network bandwidth, and EF webmaster powers to administrate those machines. The system may need to support legal requirements in some way. So far it’s build on trust that Eclipse committers are in itself a trusted group. When opening it, it needs all the things like a rights management, different duplicate detection and project guessing mechanisms etc. is opening and extending automated error reporting to non-eclipse.org plugins, e.g. to member companies, worth these efforts?
Am 24.07.2015 um 20:09 schrieb Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>:
> 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 |
