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
> 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
15 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
:
is opening and extending automated error reporting to
non-eclipse.org plugins, e.g. to member companies, worth these effo
...@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
:
While
> Am 31.07.2015 um 22:01 schrieb Konstantin Komissarchik
> :
>
> 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 t
e.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
>> :
>>
&g
half 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
> :
>
> > is opening and extending automated error reporting to
&
> Am 25.07.2015 um 23:13 schrieb Gunnar Wagenknecht :
>
>> Am 25.07.2015 um 14:08 schrieb Marcel Bruch :
>>
>> 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 ef
> Am 25.07.2015 um 15:32 schrieb Konstantin Komissarchik
> :
>
> > 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 b
> Am 25.07.2015 um 14:08 schrieb Marcel Bruch :
>
> 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
> Am 25.07.2015 um 16:33 schrieb Gunnar Wagenknecht :
>
>> Am 25.07.2015 um 06:32 schrieb Konstantin Komissarchik
>> :
>>
>>> 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 onl
s-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 Ko
ompetitive.
>>
>> 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
> Am 25.07.2015 um 06:32 schrieb Konstantin Komissarchik
> :
>
> > 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 be
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 ecli
roject 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.e
> Am 24.07.2015 um 21:07 schrieb Greg Amerson :
>
>> 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 r
> Am 24.07.2015 um 19:55 schrieb Max Rydahl Andersen :
>
> 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
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,
in 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
>
>
>
>
&g
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-proje
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 th
> Am 24.07.2015 um 17:36 schrieb Gunnar Wagenknecht :
>
>> Am 24.07.2015 um 08:27 schrieb Marcel Bruch :
>>
>> 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
> Am 24.07.2015 um 08:27 schrieb Marcel Bruch :
>
> 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 co
Komissarchik
> :
>
> 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 iss
nstantin
-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 a
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 cod
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
Konstantin,
> Am 22.07.2015 um 13:01 schrieb Konstantin Komissarchik
> :
>
> 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 im
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
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 yo
> 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 E
ross 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
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 n
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.ModelProv
35 matches
Mail list logo
