clipse.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
>
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
...@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
: 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
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
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
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,
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
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
-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
-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
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
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.
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
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
-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
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
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
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
-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
-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
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
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
-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
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
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
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
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
28 matches
Mail list logo
