Re: [cross-project-issues-dev] Error reporter and third-party code

2015-11-09 Thread Marcel Bruch 
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 
> :
> 
> 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 
>> > >:
>>  
>> 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

2015-11-09 Thread Konstantin Komissarchik 
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 
:

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 
:
 
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] Blocking regression in Neon M3 JDT

2015-11-09 Thread Konstantin Komissarchik 
To close this thread…

I hit the same issue while working on Sapphire build. This gave me an 
opportunity to take another look at this issue. After some experimentation, I 
have determined that what I am hitting appears to be a PDE bug that was exposed 
by the referenced JDT compiler change in Neon M3.

Basically, the issue is that PDE feature does not require JDT feature. If you 
start with a base platform and install PDE feature, you get a portion of JDT 
installed since individual PDE bundles depend on various JDT bundles. This in 
turns causes PDE Build to invoke JDT compiler in a way that makes it trip on 
the error documented in Bug 478427.

I have opened a PDE bug.
 
Bug 481792

Two workarounds are available for those affected. Details in the two referenced 
bugs. Hopefully, this can be fixed for M4.

Thanks,

- Konstantin



From: Konstantin Komissarchik
Sent: Thursday, November 5, 2015 3:14 PM
To: Daniel Megert;Cross project issues
Subject: RE: [cross-project-issues-dev] Blocking regression in Neon M3 JDT


To further clarify… The bug that I referenced is the one that introduced the 
regression. Whatever issue it was fixing was a severity “normal”. I reopened 
the bug when we hit the regression. Let me know if I should open a separate 
blocking bug instead.

- Konstantin



From: Konstantin Komissarchik
Sent: Thursday, November 5, 2015 3:09 PM
To: Daniel Megert;Cross project issues
Subject: Re: [cross-project-issues-dev] Blocking regression in Neon M3 JDT


In Neon M3, it’s not a message you can ignore. The build is aborted. See the 
Git diff in the bug.

- Konstantin



From: Daniel Megert
Sent: Thursday, November 5, 2015 3:06 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Blocking regression in Neon M3 JDT


I tend to ignore this message. The bug is marked as 'normal' and nothing is 
indicating that this is blocking something or someone. You should try to be 
more specific if you send out a note to this list that there is a blocking 
regression.

Dani



From:        Konstantin Komissarchik 
To:        Cross project issues 
Date:        05.11.2015 21:06
Subject:        [cross-project-issues-dev] Blocking regression in Neon M3 JDT
Sent by:        cross-project-issues-dev-boun...@eclipse.org




See https://bugs.eclipse.org/bugs/show_bug.cgi?id=478427
 
 ___
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