Hi
I agree. I think that the Eclipse-is-buggy hazard can be mitigated by
ensuring that any pop-up on behalf of a third party has a prominent logo
for that third party in the dialog. It may be a good idea for Eclipse
project logos to have similar prominence.
Regards
Ed Willink
On 25/07/2015 14:32, Konstantin Komissarchik wrote:
> is opening and extending automated error reporting to
non-eclipse.org <http://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-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] *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.
Legal:
3rd parties would get access to confidential data. Then these parties
would certainly need to sign some kind of NDA.
Resources:
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.
Technical:
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.
Konstantin,
is opening and extending automated error reporting to non-eclipse.org
<http://non-eclipse.org> plugins, e.g. to member companies, worth
these efforts?
Marcel
Am 24.07.2015 um 20:09 schrieb Konstantin Komissarchik
<konstantin.komissarc...@oracle.com
<mailto:konstantin.komissarc...@oracle.com>>:
> 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
_______________________________________________
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
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2015.0.6081 / Virus Database: 4392/10302 - Release Date: 07/25/15
_______________________________________________
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