> > I think those clients (which currently make ~28% of the error reports) > should actually sign-up and subscribe to their error reports >
Liferay would love to sign up, just point the way. On Fri, Jul 24, 2015 at 1:09 PM, Konstantin Komissarchik < konstantin.komissarc...@oracle.com> wrote: > > 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 > <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 > -- Greg Amerson Liferay Developer Tools Liferay, Inc. www.liferay.com
_______________________________________________ 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
