-1
We have no reliable means at assigning blame. Only guesses that are likely wrong as many times as they are right. Presenting unreliable blame information to the end user will cause many problems. Konstantin Komissarchik Senior Development Manager Eclipse Tools Group Oracle
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 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
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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
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
Version: 2015.0.6081 / Virus Database: 4392/10302 - Release
Date: 07/25/15
|
