Re: [cross-project-issues-dev] Error reporter and third-party code
Konstantin, I presented AERI to the board of directors at EclipseCon Europe last week. I also discussed with EMO whether there is a way that Eclipse would extend its current scope and start collecting error reports on behalf of others (member companies or other third parties). We came to the conclusion that the Eclipse Foundation will not collect error reports on behalf of other plug-in providers in foreseeable future. The risk that sensitive data might get shared is too high in such an uncontrolled environment and setting up a secured system that can handle this, the legal work this requires etc. is currently out of scope. But the Foundation is open to extensions to the error reporting client which allow users to share errors with arbitrary (e.g., your own or other centralized) data end-points. Marcel > Am 03.08.2015 um 17:49 schrieb Konstantin Komissarchik > <konstantin.komissarc...@oracle.com>: > > I have filled out the survey, but I do want to stress one point that I think > got missed in all the discussion… > > Doing something about auto-censored stack frames is not entirely for > third-party benefit. It is statistically improbably that all of the errors > with third-party frames are caused by third-party code, yet all that I’ve > seen collected for Sapphire are non-actionable in their current censored > form. As such, we are losing on an opportunity to improve eclipse.org > <http://eclipse.org/> code as well as third-party code. > > Thanks, > > - Konstantin > > > From: cross-project-issues-dev-boun...@eclipse.org > [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Marcel > Bruch > Sent: Monday, August 03, 2015 2:49 AM > To: Cross project issues > Subject: Re: [cross-project-issues-dev] Error reporter and third-party code > > >> Am 31.07.2015 um 22:01 schrieb Konstantin Komissarchik >> <konstantin.komissarc...@oracle.com >> <mailto:konstantin.komissarc...@oracle.com>>: >> >> While we ponder broader process and infrastructure improvements > > > To follow up on this part: So far only a few actively discussed this request. > To me, and likely to others, it’s hard to say who really is interested in > extending the scope of the error reporting and whether it’s worth taking this > to the board of directors now. > > If you (and others on this list) have a couple of minutes, please cast your > voice at this short form [1]. > > > Thank you > Marcel > > > [1] > https://docs.google.com/forms/d/1LtQ8QyMnQ1cD5XTXBdVgynGRaiKEMaUi9a0nxeRoumM/viewform > > <https://docs.google.com/forms/d/1LtQ8QyMnQ1cD5XTXBdVgynGRaiKEMaUi9a0nxeRoumM/viewform> > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > <mailto: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 > <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
Re: [cross-project-issues-dev] Error reporter and third-party code
Ok. Thanks for trying. Please remove Sapphire from the error reporting tool. The data that’s collected is not actionable. - Konstantin From: Marcel Bruch Sent: Monday, November 9, 2015 7:55 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code Konstantin, I presented AERI to the board of directors at EclipseCon Europe last week. I also discussed with EMO whether there is a way that Eclipse would extend its current scope and start collecting error reports on behalf of others (member companies or other third parties). We came to the conclusion that the Eclipse Foundation will not collect error reports on behalf of other plug-in providers in foreseeable future. The risk that sensitive data might get shared is too high in such an uncontrolled environment and setting up a secured system that can handle this, the legal work this requires etc. is currently out of scope. But the Foundation is open to extensions to the error reporting client which allow users to share errors with arbitrary (e.g., your own or other centralized) data end-points. Marcel Am 03.08.2015 um 17:49 schrieb Konstantin Komissarchik <konstantin.komissarc...@oracle.com>: I have filled out the survey, but I do want to stress one point that I think got missed in all the discussion… Doing something about auto-censored stack frames is not entirely for third-party benefit. It is statistically improbably that all of the errors with third-party frames are caused by third-party code, yet all that I’ve seen collected for Sapphire are non-actionable in their current censored form. As such, we are losing on an opportunity to improve eclipse.org code as well as third-party code. Thanks, - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Marcel Bruch Sent: Monday, August 03, 2015 2:49 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code Am 31.07.2015 um 22:01 schrieb Konstantin Komissarchik <konstantin.komissarc...@oracle.com>: While we ponder broader process and infrastructure improvements To follow up on this part: So far only a few actively discussed this request. To me, and likely to others, it’s hard to say who really is interested in extending the scope of the error reporting and whether it’s worth taking this to the board of directors now. If you (and others on this list) have a couple of minutes, please cast your voice at this short form [1]. Thank you Marcel [1] https://docs.google.com/forms/d/1LtQ8QyMnQ1cD5XTXBdVgynGRaiKEMaUi9a0nxeRoumM/viewform ___ 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
Re: [cross-project-issues-dev] Error reporter and third-party code
I have filled out the survey, but I do want to stress one point that I think got missed in all the discussion… Doing something about auto-censored stack frames is not entirely for third-party benefit. It is statistically improbably that all of the errors with third-party frames are caused by third-party code, yet all that I’ve seen collected for Sapphire are non-actionable in their current censored form. As such, we are losing on an opportunity to improve eclipse.org code as well as third-party code. Thanks, - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Marcel Bruch Sent: Monday, August 03, 2015 2:49 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code Am 31.07.2015 um 22:01 schrieb Konstantin Komissarchik konstantin.komissarc...@oracle.com: While we ponder broader process and infrastructure improvements To follow up on this part: So far only a few actively discussed this request. To me, and likely to others, it’s hard to say who really is interested in extending the scope of the error reporting and whether it’s worth taking this to the board of directors now. If you (and others on this list) have a couple of minutes, please cast your voice at this short form [1]. Thank you Marcel [1] https://docs.google.com/forms/d/1LtQ8QyMnQ1cD5XTXBdVgynGRaiKEMaUi9a0nxeRoumM/viewform ___ 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
Re: [cross-project-issues-dev] Error reporter and third-party code
While we ponder broader process and infrastructure improvements, would it be possible to make an improvement to the triage screen to handle the case of a non-actionable error report due to hidden stack frames? Currently, what I do is check this is (may be) a bug option and add the following text: This issue appears to be caused by a third-party plugin. Due to current privacy rules, we are unable to determine the identity of this plugin, so unfortunately this report is not actionable. We are working on a process improvement to be able to handle reports like this one in the future. Perhaps we could have a checkbox to do this in one gesture, ideally also accessible from quick actions menu. Thanks, - Konstantin -Original Message- 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 2:55 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code Am 25.07.2015 um 15:32 schrieb Konstantin Komissarchik konstantin.komissarc...@oracle.com: 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. I appreciate your view point and foresight on this. I agree to your assessment that knowing about errors (and fixing them) is important to remain competitive. Just a minor correction about the goals I set out: My goal was to help Eclipse projects to quickly see where their code breaks during the Mars milestone builds (cf. my first email on error reporting [1]). Later, and with support of the Eclipse Foundation, we extended the scope and kept the error reporter in Mars release. Still, the goal then was to help Eclipse projects to learn where their code breaks in the (larger) field. As a community we achieved impressive 360 FIXED bugs - alone 85 in the last month. But there is still a lot work to do. If we want to broaden the scope to the whole Eclipse ecosystem, we’d need to get serious about how much work this will cause. To be sustainable, the Foundation would need to allocate resources for such a service for a longer period and the system needs continuous improvement and maintenance to scale properly with the new demands. If we go down that road (assuming we get legal right at some point), this can’t continue as someone’s side project. It needs a commitment. How can we ensure this project will stay healthy? Marcel [1] https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10902.html ___ 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
Re: [cross-project-issues-dev] Error reporter and third-party code
Sounds reasonable to me. Please file a bug report in EPP / Logging. You’ll get the notice when a new quick action is available. Am 31.07.2015 um 22:01 schrieb Konstantin Komissarchik konstantin.komissarc...@oracle.com: While we ponder broader process and infrastructure improvements, would it be possible to make an improvement to the triage screen to handle the case of a non-actionable error report due to hidden stack frames? Currently, what I do is check this is (may be) a bug option and add the following text: This issue appears to be caused by a third-party plugin. Due to current privacy rules, we are unable to determine the identity of this plugin, so unfortunately this report is not actionable. We are working on a process improvement to be able to handle reports like this one in the future. Perhaps we could have a checkbox to do this in one gesture, ideally also accessible from quick actions menu. Thanks, - Konstantin -Original Message- 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 2:55 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code Am 25.07.2015 um 15:32 schrieb Konstantin Komissarchik konstantin.komissarc...@oracle.com: 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. I appreciate your view point and foresight on this. I agree to your assessment that knowing about errors (and fixing them) is important to remain competitive. Just a minor correction about the goals I set out: My goal was to help Eclipse projects to quickly see where their code breaks during the Mars milestone builds (cf. my first email on error reporting [1]). Later, and with support of the Eclipse Foundation, we extended the scope and kept the error reporter in Mars release. Still, the goal then was to help Eclipse projects to learn where their code breaks in the (larger) field. As a community we achieved impressive 360 FIXED bugs - alone 85 in the last month. But there is still a lot work to do. If we want to broaden the scope to the whole Eclipse ecosystem, we’d need to get serious about how much work this will cause. To be sustainable, the Foundation would need to allocate resources for such a service for a longer period and the system needs continuous improvement and maintenance to scale properly with the new demands. If we go down that road (assuming we get legal right at some point), this can’t continue as someone’s side project. It needs a commitment. How can we ensure this project will stay healthy? Marcel [1] https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10902.html ___ 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
Re: [cross-project-issues-dev] Error reporter and third-party code
Am 24.07.2015 um 19:55 schrieb Max Rydahl Andersen mande...@redhat.com: On 24 Jul 2015, at 17:27, Marcel Bruch wrote: I think those clients (which currently make ~28% of the error reports) should actually sign-up and subscribe to their error reports How do I subscribe to error reports that are filtered ? Support for this is limited. Check the Saphire alert [1] which listens to problems marked as „THIRD“. Note that the global filtering rules still apply (logged by an org.eclipse plugin, 3rd party class names likely anonymized). - or set up their own error collection to review and fix their issues themselves. ...adding another layer of error reporting will give even worse end-user experience imo - i.e. how do I know that eclipse error reporter haven't reported it ? A matter of implementation. There could be one listener that inspects the log event and delivers it different endpoints based on some criteria - or to the same endpoint (e.g eclipse.org if Eclipse would start collecting error reports for, say, its member companies - and for their commercial products / non-eclipse.org http://non-eclipse.org/ plugins?). Marcel [1] https://dev.eclipse.org/recommenders/committers/confess/#/projects/54d39c63e4b0d2e72753bc99 https://dev.eclipse.org/recommenders/committers/confess/#/projects/54d39c63e4b0d2e72753bc99 -- 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
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: 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
Re: [cross-project-issues-dev] Error reporter and third-party code
Am 24.07.2015 um 21:07 schrieb Greg Amerson gregory.amer...@liferay.com: 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. Unfortunately, this is yet not possible - and one reason why we do have this discussion. To make that happen, at some point this needs to be taken to the board of directors and needs a couple of supporters there, I guess. Marcel ___ 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
Re: [cross-project-issues-dev] Error reporter and third-party code
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
Re: [cross-project-issues-dev] Error reporter and third-party code
There are two separate aspects... 1. Allowing the vendors to actually subscribe to the error reports. This is aimed at letting vendors help themselves. 2. Revising the system for censoring stack frames. This is aimed at facilitating project committers in investigating the error reports that land in their inbox by allowing them to know who they should be talking to. A more flexible system allowing parties to be added to the list of namespaces that aren't censored would be valuable, especially if coupled with improved defaulting/prompting on the client. One thing to consider is how would we handle vendors who are not aware of the error reporting system operated by Eclipse Foundation or at least are not aware that they can take advantage of it. We could collect a list of namespaces that are being censored and have someone in an elevated trust position (Eclipse Foundation staff?) attempt to contact these vendors to inform them of the error collection system and how they can advantage of it. Ideally, we address both of these aspects. #2 may be more achievable in the short term (SR1). Thanks, - Konstantin -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Gunnar Wagenknecht Sent: Saturday, July 25, 2015 7:33 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code Am 25.07.2015 um 06:32 schrieb Konstantin Komissarchik konstantin.komissarc...@oracle.com: 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. Marcel, What about a program that allows any vendor to opt-out of the filtering? It could be as simple as requesting a vendor to open a Bugzilla and/or submit an agreement form to the Eclipse Foundation listening the package namespaces which should not be filtered anymore. -Gunnar ___ 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
Re: [cross-project-issues-dev] Error reporter and third-party code
-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 On Jul 25, 2015, at 06:54, Ed Willink e...@willink.me.uk wrote: 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 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 plugins, e.g. to member companies, worth these efforts? Marcel Am 24.07.2015 um 20:09 schrieb Konstantin Komissarchik 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
Re: [cross-project-issues-dev] Error reporter and third-party code
Am 25.07.2015 um 16:33 schrieb Gunnar Wagenknecht gun...@wagenknecht.org: Am 25.07.2015 um 06:32 schrieb Konstantin Komissarchik konstantin.komissarc...@oracle.com: 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. Marcel, What about a program that allows any vendor to opt-out of the filtering? It could be as simple as requesting a vendor to open a Bugzilla and/or submit an agreement form to the Eclipse Foundation listening the package namespaces which should not be filtered anymore. I’ve no strong opinion on that yet (and likely the EF and legal will have to final say). *My* current gut feeling is that it should be opt-in. Opt-outs, however, will be more effective to get a comprehensive view. Opting out via bugzilla or something else looks like something that needs to be managed and maintained - and thus needs constant resources. But there might be alternatives like an extension point where plugins can register ignored namespaces“ to the error reporter. Just thinking loud. Marcel ___ 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
Re: [cross-project-issues-dev] Error reporter and third-party code
Am 25.07.2015 um 14:08 schrieb Marcel Bruch marcel.br...@codetrails.com: I’ve no strong opinion on that yet (and likely the EF and legal will have to final say). *My* current gut feeling is that it should be opt-in. Opt-outs, however, will be more effective to get a comprehensive view. Ha! I've struggled myself when writing this and decided on opt out of filtering, which I translate to: filter vendor packages by default like today but can say hey, don't hide my packages. ;) -Gunnar ___ 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
Re: [cross-project-issues-dev] Error reporter and third-party code
Am 25.07.2015 um 23:13 schrieb Gunnar Wagenknecht gun...@wagenknecht.org: Am 25.07.2015 um 14:08 schrieb Marcel Bruch marcel.br...@codetrails.com: I’ve no strong opinion on that yet (and likely the EF and legal will have to final say). *My* current gut feeling is that it should be opt-in. Opt-outs, however, will be more effective to get a comprehensive view. Ha! I've struggled myself when writing this and decided on opt out of filtering, which I translate to: filter vendor packages by default like today but can say hey, don't hide my packages. ;) Sorry, I misread your proposal :-) This may be an option (or using extension points to opt-in collecting / opt-out from filtering) ___ 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
Re: [cross-project-issues-dev] Error reporter and third-party code
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-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 plugins, e.g. to member companies, worth these efforts? Marcel Am 24.07.2015 um 20:09 schrieb Konstantin Komissarchik 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
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 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
Re: [cross-project-issues-dev] Error reporter and third-party code
Am 24.07.2015 um 17:36 schrieb Gunnar Wagenknecht gun...@wagenknecht.org: Am 24.07.2015 um 08:27 schrieb Marcel Bruch marcel.br...@codetrails.com: 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. How did you get that information? I thought it's currently not submitted to Eclipse.org or any other entity? it’s actually a sloppy implementation in the bundle guessing section of an error report. Also the eclipse product/build-ids are not restricted which contain information whther a problem was reported by the Spring Tools Suite for example. Marcel -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org, http://guw.io/ ___ 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
Re: [cross-project-issues-dev] Error reporter and third-party code
Am 24.07.2015 um 08:27 schrieb Marcel Bruch marcel.br...@codetrails.com: 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. How did you get that information? I thought it's currently not submitted to Eclipse.org or any other entity? -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org, http://guw.io/ ___ 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
Re: [cross-project-issues-dev] Error reporter and third-party code
On 24 Jul 2015, at 17:27, Marcel Bruch wrote: I think those clients (which currently make ~28% of the error reports) should actually sign-up and subscribe to their error reports How do I subscribe to error reports that are filtered ? - or set up their own error collection to review and fix their issues themselves. ...adding another layer of error reporting will give even worse end-user experience imo - i.e. how do I know that eclipse error reporter haven't reported it ? /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
Re: [cross-project-issues-dev] Error reporter and third-party code
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
Re: [cross-project-issues-dev] Error reporter and third-party code
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
Re: [cross-project-issues-dev] Error reporter and third-party code
Stack frames should not be considered sensitive just because they are from a non-OSS code base. Users post stack traces with commercial code references in forums all the time. Just because they can doesn't imply the are allowed to. There are all sorts of liability questions in here which I can understand as a reason to hide those. I think there is no other option. For most commercial code, the user can not simply allow disclosing such information but a vendor would have to approve. As long as we make it an explicit user choice whether convey this information to eclipse.org, I don't see how it's any different from user making an explicit choice to convey this information to say stackoverflow. The burden is on the user to comply with whatever policy or license obligations might bind them. How about this system: 1. The top-level package names are extracted from the stack trace. 2. The list is checked against an authorized list, which starts out populated with OSS namespaces. 3. If entries are found that aren't on the authorized list, the user gets a prompt like the following: An error was detected that includes stack frames with the following namespaces that you have not yet authorized for reporting to Eclipse Foundation. [list of namespaces] [Authorize] [Authorize Once] [Do Not Report] Looking at the stack trace, I read it as some Sapphire code is initializing a data service which is implemented/provided by an adopter. That adopter calls some WTP code which fails. From a Sapphire perspective it shouldn't matter if it's a WTP issue, i.e. it's the adopter's code which is failing. This should be handled in a way that an adopter realizes it. For example, Sapphire should catch the root exception and wrap it into a Sapphire specific error message which is then either presented to the user or logged to a log file. From an Eclipse.org error handler perspective, this error message should probably then be marked as log message. It really isn't Sapphires fault here. My goal is not to remove blame from Sapphire, but to improve the quality across the Eclipse ecosystem. As such, the proposed strategy doesn't help. My bottom line... Censored stack traces are useless. At the minimum, anything that would be censored should not be reported. Ideally, we should have a better system in place that avoids the need to censor so that we can help adopters improve their code and let them help us by exposing errors that are only evident in adopter scenarios. Thanks, - Konstantin -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Gunnar Wagenknecht Sent: Thursday, July 23, 2015 9:29 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code Konstantin, Am 22.07.2015 um 13:01 schrieb Konstantin Komissarchik konstantin.komissarc...@oracle.com: Stack frames should not be considered sensitive just because they are from a non-OSS code base. Users post stack traces with commercial code references in forums all the time. Just because they can doesn't imply the are allowed to. There are all sorts of liability questions in here which I can understand as a reason to hide those. I think there is no other option. For most commercial code, the user can not simply allow disclosing such information but a vendor would have to approve. Anyway, I have a different view on your particular topic, which might be a possible approach for other adopters. Looking at the stack trace, I read it as some Sapphire code is initializing a data service which is implemented/provided by an adopter. That adopter calls some WTP code which fails. From a Sapphire perspective it shouldn't matter if it's a WTP issue, i.e. it's the adopter's code which is failing. This should be handled in a way that an adopter realizes it. For example, Sapphire should catch the root exception and wrap it into a Sapphire specific error message which is then either presented to the user or logged to a log file. From an Eclipse.org error handler perspective, this error message should probably then be marked as log message. It really isn't Sapphires fault here. BTW, the NPE in WTP is bad, though. But we simply can't now if it's a bug in WTP or if the adopter failed to initialize/setup some expected variables. But it should be the adopter investigating it. -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org, http://guw.io/ ___ 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
Re: [cross-project-issues-dev] Error reporter and third-party code
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
Re: [cross-project-issues-dev] Error reporter and third-party code
'instance of Eclipse' is ambiguous. I mean the Eclipse installation. The reason I think this scope is the correct one is as that's where the plugins reside that the user is asked to make a choice regarding. For instance, I might have one installation with pre-release code that's private and another installation with all released code that's ok to report. If the choice is persisted in the workspace that seems too dangerous, one accidental answer and Eclipse becomes leaky. Accidental answers can happen regardless of which approach we use. Obviously, we would need a preference system for changing the preference after the initial prompt. Persisting only until the next Eclipse restart seems like a good idea. That seems highly unworkable. I don't know of any user who would tolerate constant prompting like that. Thanks, - Konstantin -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ed Willink Sent: Wednesday, July 22, 2015 9:28 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Error reporter and third-party code Hi IMHO, the 20% who explicitly enabled message anonymization will also enable method anonymization because they are avoiding the problem of needing corporate approval of any release of data. A method name such as SHA4096 may reveal what algorithm is being exploited/developed. Too risky if you are not sure. My proposal: When a we detect a non-OSS stack frame, we actively ask the user to make a choice that’s then persisted for that instance of Eclipse. 'instance of Eclipse' is ambiguous. If the choice is persisted in the workspace that seems too dangerous, one accidental answer and Eclipse becomes leaky. Persisting only until the next Eclipse restart seems like a good idea. Regards Ed Willink On 22/07/2015 22:39, Marcel Bruch wrote: My proposal:… Sounds okay to me. I wonder if the short cut „not to enable 3rd party class names in stack traces by default“ would be acceptable as well since it’s right on the configure dialog and easy to grasp (IMHO). Wayne, any thoughts on this? I can change the defaults (for SR1) if the EF would agree. FWIW, during the milestone build (until June 20th) 20% of the users explicitly enabled „message anonymization“ because they feared that the message may contains sensitive data. I’d expect that users are less concerned about method names. I’d need to validate this number with the current reporter base to give a more reliable statement, though. I strongly conclude that if someone would have cared at that time, they would have had the chance to participate from the very first moment. I brought up the issue of better handling third-party plugins several times from the very beginning and was brushed off. I did a quick search for earlier discussions on this topic and found [1] from August 2014. I don’t have the impression you were brushed off in that discussion - but nevertheless: If I did (there or somewhere else) I apologize for that. Best, Marcel [1] https://dev.eclipse.org/mhonarc/lists/epp-dev/msg03193.html 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 Version: 2015.0.6081 / Virus Database: 4392/10286 - Release Date: 07/22/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 ___ 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
Re: [cross-project-issues-dev] Error reporter and third-party code
Konstantin, let me send this at the beginning: this discussion is greatly appreciated - although my personal answer might not be satisfying yet… Library projects like Sapphire or Nebula are somewhat special because they are (more or less) exclusively used by third-party plugins. Hence they do not benefit that much from the privacy defaults. First question… Why are third-party stack frames hidden? Although your questions may give a different impression, I assume that you and everyone else understands why classnames from non-eclipse/non-apache bundles are replaced by HIDDEN.HIDDEN by default. No matter if one does or not, one may ask the following questions (again) and judge differently now (after ten thousands of users reported ~170K errors in the last 30 days): (i) whether a class name in a stacktrace should be considered as potentially private information“, and (ii) whether it should be anonymized by default. When we (Eclipse Foundation staff and me) discussed the legal implications of the error reporting we came to the conclusion that a class name may reveal sensitive information and thus should be anonymized by default. Are the notes from when this was originally considered captured somewhere? The discussion about what to anonymize and how took place on August 2014. First with the Eclipse Foundation Staff in a couple of conference calls and then published and summarized in several mails to cross-projects-issues-...@eclipse.org. I strongly conclude that if someone would have cared at that time, they would have had the chance to participate from the very first moment. Let me know if you need me to pull up all emails and slides I sent to cross-projects regarding the error reporting at that time. I’m pretty sure the whole process was quite transparent at any time and visible to everyone starting from M1 to RC4 :-) I have contact info for many Sapphire adopters. If I knew who to contact, I could actually follow up on these error reports. IMHO this is more a legal question then a technical one. It all depends how lawyers (and users) judge on the two questions above. I can imagine that - if member companies agree to collect their error reports at eclipse.org OR to opt-in to disable anonymization for their bundles and namespaces - we can reduce the number of HIDDEN in your error reports. But as I said, this would need the support of the Eclipse foundation and like of the member companies. 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? Regards, Marcel ___ 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
Re: [cross-project-issues-dev] Error reporter and third-party code
My proposal:… Sounds okay to me. I wonder if the short cut „not to enable 3rd party class names in stack traces by default“ would be acceptable as well since it’s right on the configure dialog and easy to grasp (IMHO). Wayne, any thoughts on this? I can change the defaults (for SR1) if the EF would agree. FWIW, during the milestone build (until June 20th) 20% of the users explicitly enabled „message anonymization“ because they feared that the message may contains sensitive data. I’d expect that users are less concerned about method names. I’d need to validate this number with the current reporter base to give a more reliable statement, though. I strongly conclude that if someone would have cared at that time, they would have had the chance to participate from the very first moment. I brought up the issue of better handling third-party plugins several times from the very beginning and was brushed off. I did a quick search for earlier discussions on this topic and found [1] from August 2014. I don’t have the impression you were brushed off in that discussion - but nevertheless: If I did (there or somewhere else) I apologize for that. Best, Marcel [1] https://dev.eclipse.org/mhonarc/lists/epp-dev/msg03193.html 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
Re: [cross-project-issues-dev] Error reporter and third-party code
I assume that you and everyone else understands why classnames from non-eclipse/non-apache bundles are replaced by HIDDEN.HIDDEN by default. I can imagine cases, such as pre-release products and internal solutions, where stack frames contain sensitive information, but that isn’t the general case. Stack frames should not be considered sensitive just because they are from a non-OSS code base. Users post stack traces with commercial code references in forums all the time. Companies that worry about this sort of thing scramble their bytecode. User should not be expected to know how to change preferences to turn off filtering as none of them will bother to do so, especially as the error reporting system gives them the impression that the error reports are actionable with information omitted. My proposal: When a we detect a non-OSS stack frame, we actively ask the user to make a choice that’s then persisted for that instance of Eclipse. If they make a choice indicating that non-OSS references are sensitive, we don’t even bother sending an error report. I have yet to see an error report with hidden frames that was actionable. This active choice should be viewed as equivalent to user making a choice to grab a stack from the log and post it on the forum. I strongly conclude that if someone would have cared at that time, they would have had the chance to participate from the very first moment. I brought up the issue of better handling third-party plugins several times from the very beginning and was brushed off. Thanks, - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Marcel Bruch Sent: Wednesday, July 22, 2015 11:37 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code Konstantin, let me send this at the beginning: this discussion is greatly appreciated - although my personal answer might not be satisfying yet… Library projects like Sapphire or Nebula are somewhat special because they are (more or less) exclusively used by third-party plugins. Hence they do not benefit that much from the privacy defaults. First question… Why are third-party stack frames hidden? Although your questions may give a different impression, I assume that you and everyone else understands why classnames from non-eclipse/non-apache bundles are replaced by HIDDEN.HIDDEN by default. No matter if one does or not, one may ask the following questions (again) and judge differently now (after ten thousands of users reported ~170K errors in the last 30 days): (i) whether a class name in a stacktrace should be considered as potentially private information“, and (ii) whether it should be anonymized by default. When we (Eclipse Foundation staff and me) discussed the legal implications of the error reporting we came to the conclusion that a class name may reveal sensitive information and thus should be anonymized by default. Are the notes from when this was originally considered captured somewhere? The discussion about what to anonymize and how took place on August 2014. First with the Eclipse Foundation Staff in a couple of conference calls and then published and summarized in several mails to cross-projects-issues-...@eclipse.org. I strongly conclude that if someone would have cared at that time, they would have had the chance to participate from the very first moment. Let me know if you need me to pull up all emails and slides I sent to cross-projects regarding the error reporting at that time. I’m pretty sure the whole process was quite transparent at any time and visible to everyone starting from M1 to RC4 :-) I have contact info for many Sapphire adopters. If I knew who to contact, I could actually follow up on these error reports. IMHO this is more a legal question then a technical one. It all depends how lawyers (and users) judge on the two questions above. I can imagine that - if member companies agree to collect their error reports at eclipse.org OR to opt-in to disable anonymization for their bundles and namespaces - we can reduce the number of HIDDEN in your error reports. But as I said, this would need the support of the Eclipse foundation and like of the member companies. 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? Regards, Marcel ___ 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
Re: [cross-project-issues-dev] Error reporter and third-party code
Hi IMHO, the 20% who explicitly enabled message anonymization will also enable method anonymization because they are avoiding the problem of needing corporate approval of any release of data. A method name such as SHA4096 may reveal what algorithm is being exploited/developed. Too risky if you are not sure. My proposal: When a we detect a non-OSS stack frame, we actively ask the user to make a choice that’s then persisted for that instance of Eclipse. 'instance of Eclipse' is ambiguous. If the choice is persisted in the workspace that seems too dangerous, one accidental answer and Eclipse becomes leaky. Persisting only until the next Eclipse restart seems like a good idea. Regards Ed Willink On 22/07/2015 22:39, Marcel Bruch wrote: My proposal:… Sounds okay to me. I wonder if the short cut „not to enable 3rd party class names in stack traces by default“ would be acceptable as well since it’s right on the configure dialog and easy to grasp (IMHO). Wayne, any thoughts on this? I can change the defaults (for SR1) if the EF would agree. FWIW, during the milestone build (until June 20th) 20% of the users explicitly enabled „message anonymization“ because they feared that the message may contains sensitive data. I’d expect that users are less concerned about method names. I’d need to validate this number with the current reporter base to give a more reliable statement, though. I strongly conclude that if someone would have cared at that time, they would have had the chance to participate from the very first moment. I brought up the issue of better handling third-party plugins several times from the very beginning and was brushed off. I did a quick search for earlier discussions on this topic and found [1] from August 2014. I don’t have the impression you were brushed off in that discussion - but nevertheless: If I did (there or somewhere else) I apologize for that. Best, Marcel [1] https://dev.eclipse.org/mhonarc/lists/epp-dev/msg03193.html 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 Version: 2015.0.6081 / Virus Database: 4392/10286 - Release Date: 07/22/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
[cross-project-issues-dev] Error reporter and third-party code
I've been watching the error reports trickling into the Sapphire inbox, but unfortunately none of them have been actionable so far. The issue is interaction with third-party code. Consider the following stack trace: java.lang.NullPointerException: HIDDEN at org.eclipse.jst.j2ee.model.ModelProviderManager.getModelProvider(ModelProvid erManager.java:101) at org.eclipse.jst.j2ee.model.ModelProviderManager.getModelProvider(ModelProvid erManager.java:281) at HIDDEN.HIDDEN(HIDDEN:-1) at HIDDEN.HIDDEN(HIDDEN:-1) at org.eclipse.sapphire.PossibleValuesService.initDataService(PossibleValuesSer vice.java:68) at org.eclipse.sapphire.services.DataService.init(DataService.java:54) at org.eclipse.sapphire.services.Service.initIfNecessary(Service.java:60) at org.eclipse.sapphire.services.ServiceContext.services(ServiceContext.java:21 7) at org.eclipse.sapphire.Property.services(Property.java:535) at org.eclipse.sapphire.Property.service(Property.java:505) at org.eclipse.sapphire.services.internal.PossibleValuesValidationService$Condi tion.applicable(PossibleValuesValidationService.java:82) at org.eclipse.sapphire.services.ServiceProxy.service(ServiceProxy.java:99) at org.eclipse.sapphire.services.ServiceContext.services(ServiceContext.java:17 6) There are three codebases interacting here: Sapphire, WTP and some unknown third-party plugin. Without knowing the hidden details in order to be able to initiate a discussion with the third-party, this error report is not actionable. This is not an isolated case or a minority of cases. Literally all reports received so far for Sapphire are like that. I know that there are other leaf projects with a similar issue. Now that we have a solution for capturing and hopefully handling errors that only involve eclipse.org code, let's have a serious discussion on how we can handle error reports involving third-party code. First question. Why are third-party stack frames hidden? Are the notes from when this was originally considered captured somewhere? I have contact info for many Sapphire adopters. If I knew who to contact, I could actually follow up on these error reports. 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
