Re: [cross-project-issues-dev] Withdrawing Code Recommenders from SimRel

[Marcel Bruch]

I request option 3 for the sake of the better user experience (i.e., not doing 
2). Option 1 is not feasible given the current constraints.

Best regards,
Marcel

Von meinem iPad gesendet

> Am 12.12.2018 um 17:15 schrieb Andreas Sewe :
> 
> Wayne Beaton wrote:
>> AFAICT, Eclipse Code Recommenders has been removed from the packages. I
>> do, however, see references to what I think look like references to
>> org.eclipse.recommenders.news.rcp bundle (optional) and extension point
>> in a couple of plugin.xml and MANIFEST files. Should these be removed?
> 
> that is not necessary. The News Feed bundle is optional and unrelated to
> the rest of Code Recommenders. Unfortunately, it is currently broken as
> the Feed Parser in Mylyn broke [1] with Java 11 (JAXB being removed).
> The feed declarations are still there to provide users who install the
> plugin from the Marketplace automatically are subscribed to the
> packages' feed.
> 
>> We're very late in the process. Staging for the final RC is currently in
>> progress (the final build for RC2 starts at midnight EST). This feels
>> like too significant a change to commit after the final RC.
>> 
>> I believe that we have three choices:
>> 
>> 1) Stay in 2018-12 and contribute new bits
>> 2) Stay in 2018-12 and contribute the old bits
>> 3) Drop out of 2018-12 and remove the old bits
>> 
>> I am I correct in assuming that the second option is actually invalid?
> 
> I don't have a running build right now (and can't work full-time on
> this) so option 1 seems unlikely at this point; Java 11 simply broke to
> many things in our build.
> 
> Under Java 11, option 2 logs several errors in the Error Log the first
> time the user triggers content assist in a Java file. Thereafter, JDT
> completion works as normal and Code Recommenders doesn't.
> 
> To ensure that Java users have a smooth out-of-the-box experience, I
> personally would vote for option 3.
> 
>> I think that we need a final call (from the Project Lead) right now.
> 
> @Marcel: What's your take on this?
> 
> Hope this helps.
> 
> Andreas
> 
> [1] <https://bugs.eclipse.org/bugs/show_bug.cgi?id=539681>
> 
> -- 
> Codetrails GmbH
> The best code possible
> 
> Robert-Bosch-Str. 7, 64293 Darmstadt
> Mobile: +49-170-811-3791
> 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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Withdrawing Code Recommenders from SimRel

[Marcel Bruch]

Sorry. Didn‘t notice that Andreas already answered.



Von meinem iPad gesendet

> Am 12.12.2018 um 07:11 schrieb Marcel Bruch :
> 
> Hi Wayne,
> 
> Andreas is trying to fix this but it looks like he can‘t make it in addition 
> to his other duties :-( I‘ll wait until the end of this week before making 
> the final announcement to see if Andreas gets things running once more.
> 
> But my current assumption is: Starting with 2018-12.
> 
> Marcel
> 
> Von meinem iPad gesendet
> 
>> Am 11.12.2018 um 21:53 schrieb Wayne Beaton 
>> :
>> 
>> Starting when?
>> 
>> i.e. is Eclipse Code Recommenders still in for 2018-12?
>> 
>> Thanks,
>> 
>> Wayne
>> 
>>> On Tue, Dec 11, 2018 at 3:49 PM Marcel Bruch  
>>> wrote:
>>> Dear Cross-Projects,
>>> 
>>> I‘d like to withdraw Code Recommenders participation from the SimRel and 
>>> EPP packages.
>>> 
>>> The project committers currently do not have enough resources to keep pace 
>>> with the changes in JDT/Java and thus we‘ve to take this necessary and long 
>>> due action.
>>> 
>>> Best,
>>> Marcel
>>> 
>>> Von meinem iPad gesendet
>>> ___
>>> 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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> 
>> 
>> -- 
>> Wayne Beaton
>> Director of Open Source Projects | Eclipse Foundation, Inc.
>> ___
>> 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://www.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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Withdrawing Code Recommenders from SimRel

[Marcel Bruch]

Hi Wayne,

Andreas is trying to fix this but it looks like he can‘t make it in addition to 
his other duties :-( I‘ll wait until the end of this week before making the 
final announcement to see if Andreas gets things running once more.

But my current assumption is: Starting with 2018-12.

Marcel

Von meinem iPad gesendet

> Am 11.12.2018 um 21:53 schrieb Wayne Beaton 
> :
> 
> Starting when?
> 
> i.e. is Eclipse Code Recommenders still in for 2018-12?
> 
> Thanks,
> 
> Wayne
> 
>> On Tue, Dec 11, 2018 at 3:49 PM Marcel Bruch  
>> wrote:
>> Dear Cross-Projects,
>> 
>> I‘d like to withdraw Code Recommenders participation from the SimRel and EPP 
>> packages.
>> 
>> The project committers currently do not have enough resources to keep pace 
>> with the changes in JDT/Java and thus we‘ve to take this necessary and long 
>> due action.
>> 
>> Best,
>> Marcel
>> 
>> Von meinem iPad gesendet
>> ___
>> 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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> 
> -- 
> Wayne Beaton
> Director of Open Source Projects | Eclipse Foundation, Inc.
> ___
> 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://www.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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Withdrawing Code Recommenders from SimRel

[Marcel Bruch]

Dear Cross-Projects,

I‘d like to withdraw Code Recommenders participation from the SimRel and EPP 
packages.

The project committers currently do not have enough resources to keep pace with 
the changes in JDT/Java and thus we‘ve to take this necessary and long due 
action.

Best,
Marcel

Von meinem iPad gesendet
___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Guava versions in Oxygen

[Marcel Bruch]

Dear planning council,
Dear Eclipse committers,


I strongly question this decision for the following technical reasons. The 
arguments referenced at [1] have been discussed controversially and have severe 
drawbacks:

Upgrading to Guava 21 forces every project with Guava classes in their public 
API to make a new major release with every new Eclipse release. Otherwise we’d 
break every existing client out there (of Mylyn, of Code Recommenders, or every 
commercial or in-house project that builds on Xtext) for no good.
Version ranges (in require-bundle or import-packages) will be required in any 
case: Even with the proposed solution, we will have the same problem as today 
as soon as any other 3rd party requires/uses a later version of Guava. Thus, 
forcing a subset of Eclipse plugins to use Guava 21 w/o version ranges will 
break plug-ins.
The argument made in [2] that uses directives are "too hard to use" is weak 
and, in my opinion, does not justify the drawbacks of 1 & 2.

I understand that all projects that rely on Xtext (as Ed’s projects) suffer 
from the fact that different versions of Guava can be around and thus can cause 
wiring issues. But the proposed solution does that fix for Ed’s use case but 
breaks an unknown number of clients out there we don’t know yet. IMO (and 
others supported that previously), this is a effort that needs (and can!) to be 
solved by the Xtext community - but not on the cost of every other project out 
there.

I, however, agree with the statement (made in [2] as well) "Please move to 
Guava 21. If you can do accurate 'uses' directives, please do that”. Projects 
that can properly make use of uses directives should not be forced to update 
their code and all clients to Guava 21, Guava 22, Guava 23…

I’ll take this to the architecture council on next Thursday for further 
discussion. Since several planning council members are also on this council, I 
think we’ll have every interest group represented there. If not, I’m sure the 
AC welcomes every other committer to join this call.


Marcel



[1] https://wiki.eclipse.org/Planning_Council/May_03_2017
[2] https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14350.html


> On 5. May 2017, at 10:04, Aleksandar Kurtakov  wrote:
> 
> On the last Planning council meeting we discussed Guava and having
> multiple versions of it in Oxygen. In order to prevent issues like
> there were with multiple Guava versions in Luna and/or issues like
> with Neon.3 we are strongly recommending that:
> 
> Every project that depends on Guava moves to version 21 for Oxygen.
> 
> 
> Guava 21 is available in Oxygen's M6 repo so please file your PB CQs
> and move up ASAP.
> Detailed report of all the API changes since version 15 (the version
> in Neon) can be found at
> https://github.com/google/guava/wiki/ReleaseHistory .
> 
> Don't hesitate to ask if there is anything unclear.
> 
> -- 
> Alexander Kurtakov
> Red Hat Eclipse Team
> ___
> 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] [eclipse.org-planning-council] Neon.3 update problem status

[Marcel Bruch]

Hi Carsten,

did any of the three scenarios previously result in an error? In other words: 
Was the problem reproducible for you and is that reproducible situation now 
fixed?

Thanks,
Marcel

> On 8. May 2017, at 13:34, Carsten Reckord  wrote:
> 
> Hi all,
> 
> I have tested the respin candidate with MPC, and it looks good. I've tested 3 
> scenarios, using the JavaEE EPP package:
> 
> 1. Neon.2 with Docker Tools and Oomph installed, updated to Neon.3a
> -> works, and the offending HttpClient is not installed
> 
> 2. Direct install of Neon.3a with Docker Tools and Oomph
> -> works, and the offending HttpClient is not installed
> 
> 3. Neon.3 with Docker Tools and Oomph installed, updated to Neon.3a
> -> this still contains the broken HttpClient (as mentioned before). However, 
> at least in my tests, it looks like it was only wired to bundles requiring 
> only the package subset actually present in the bundle, and there were no 
> wiring issues through package exports that I could see. Specifically, both 
> USS and MPC were wired to the 4.3.6 version, so that potential conflict was 
> resolved properly.
> 
> After the initial update, I ran each resulting Neon.3a instance a couple of 
> times with -clean and/or -initialize to see if that changed the wiring 
> somehow, but didn't run into problems.
> 
> Best,
> Carsten
> 
>> -Original Message-
>> From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-
>> issues-dev-boun...@eclipse.org] On Behalf Of Frederic Gurr
>> Sent: Thursday, May 4, 2017 1:18 AM
>> To: Cross project issues 
>> Subject: Re: [cross-project-issues-dev] [eclipse.org-planning-council]
>> Neon.3 update problem status
>> 
>> Hi Ed,
>> 
>> The corresponding EPP repository can be found here:
>> 
>> https://hudson.eclipse.org/packaging/job/neon.epp-tycho-
>> build/599/artifact/org.eclipse.epp.packages/archive/repository/
>> 
>> Regards,
>> 
>> Fred
>> 
>> On 28.04.2017 10:25, Ed Merks wrote:
>>> Fred,
>>> 
>>> If someone would let me know when there is a corresponding EPP
>>> repository available, I can do some further testing.   With regard to
>>> your specific question, if the p2.inf can specify an exact bundle
>>> version to remove that's probably a good idea.   And by exact I mean
>>> that it would only remove the known-to-be-broken versions of these
>>> bundles that no one should ever have used and no one should ever use in
>>> the future.  Those broken versions have never been in a "released"
>>> repository, except for Neon.3.  It should not remove newer versions of
>>> the fixed bundles, even though those might cause the same wiring
>>> problems.  That being said, I think a main contributing factor to the
>>> wiring problem is the constraints that were added to exclude higher
>>> versions.   I know for example that oomph and userstorage work fine with
>>> the latest versions of these bundles but it was constrained not to use
>>> to exclude the broken versions for Oomph 1.1.
>>> 
>>> I hope that everyone who added such constraints will be sure to remove
>>> them for Oxygen M7.  Oomph's 1.8 contribution to Oxygen will use and
>>> contribute the latest versions of those bundles...
>>> 
>>> 
>>> On 27.04.2017 22:14, Frederic Gurr wrote:
 Open questions:
 - Do we need to use the uninstall command in p2.inf to remove old Http*
 bundles for users that already upgraded to Neon.3 and have a broken
 setup at the moment? How would that affect 3rd party plugins that might
 bring their own HttpClient version (Martin's question)?
>>> 
>>> ___
>>> eclipse.org-planning-council mailing list
>>> eclipse.org-planning-coun...@eclipse.org
>>> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>>> 
>>> IMPORTANT: Membership in this list is generated by processes internal to
>>> the Eclipse Foundation.  To be permanently removed from this list, you
>>> must contact e...@eclipse.org to request removal.
>> ___
>> 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

___
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] Neon.3 update problem status

[Marcel Bruch]

Fred,

that sounds very promising! Many thanks to you, Ed, Tom and all other people 
who made that happen!

> On 27. Apr 2017, at 22:14, Frederic Gurr  wrote:
> 
> - Are we confident that solution B works for all affected components
> (MPC, Oomph, USS, Code Recommenders, others)?
> 
> I'd like to run the Neon.3 respin next week, if possible. So please
> provide test feedback!!


I’m / we are not able to run deeper tests for Code Recommenders until Tuesday 
(holidays). But we’ll report back on Tuesday morning CEST.

Again, many thanks!
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] Neon.3 Update Problems: To Fix and How to Fix?

[Dr. Marcel Bruch]

>>>> <mailto:cross-project-issues-dev@eclipse.org>
>><mailto:cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>>
>>><mailto:cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>><mailto: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>
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
>>> 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
>>>>>> 
>>> 
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>> 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
>>>>>> 
>>>>>___
>>>>>cross-project-issues-dev mailing list
>>>>>cross-project-issues-dev@eclipse.org
>><mailto:cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>>
>>><mailto:cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>><mailto:cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>>>
>>>>><mailto:cross-project-issues-dev@eclipse.org 
>>>>> <mailto:cross-project-issues-dev@eclipse.org>
>><mailto:cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>>
>>><mailto:cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>><mailto: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>
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
>>> 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
>>>>> 
>>> 
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>> 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
>>>> 
>>>> 
>>>>___
>>>>cross-project-issues-dev mailing list
>>>>cross-project-issues-dev@eclipse.org
>><mailto:cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>>
>>><mailto:cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>><mailto:cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>>>
>>>><mailto:cross-project-issues-dev@eclipse.org 
>>>> <mailto:cross-project-issues-dev@eclipse.org>
>><mailto:cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>>
>>><mailto:cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>><mailto: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>
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
>>> 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
>>>> 
>>> 
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>> 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> cross-project-issues-dev mailing list
>>>> cross-project-issues-dev@eclipse.org
>><mailto:cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>>
>>><mailto:cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>><mailto: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>
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
>>> 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
>>>> 
>>>___
>>>cross-project-issues-dev mailing list
>>>cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>><mailto:cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>>
>>><mailto:cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>><mailto: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>
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
>>> 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>><mailto: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>
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
>>> 
>>___
>>cross-project-issues-dev mailing list
>>cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>
>><mailto: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>
>><https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
>> 
>> 
>> 
>> 
>> ___
>> 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>
>> 
> ___
> 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] Neon.3 Update Problems: To Fix and How to Fix?

[Dr. Marcel Bruch]

Hi Fred,

Code Recommenders also suffers from the addition of the new HTTPClient. 
Unfortunately our build master is on holidays for two weeks and I don’t know 
all details yet.

However, Bug 513809 summarizes all his findings. Maybe that bug contains 
relevant information to understand the issues Code Recommenders has and to find 
the right resolution for Neon.3a.

In a nutshell, we have a version for Oxygen M7 that should work with the latest 
HTTPClient (on the oxygen simrel update site) and the Neon version that only 
works with the old version of HTTPClient. Depending on which solution you try 
out, we may have to use different update sites.

LMK if I can be of any help here. I’m happy to test all builds to see if they 
solve all issues in Code Recommenders.

Marcel

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=513809


> On 19 Apr 2017, at 21:19, Wayne Beaton <wa...@eclipse.org> wrote:
> 
> I've added my notes to the meeting minutes. These notes do not provide any 
> more detail than what's been discussed in this and the planning council 
> mailing lists.
> 
> My apologies for the delay.
> 
> Wayne
> 
> 
> On 19/04/17 11:13 AM, Ed Merks wrote:
>> 
>> There seem to have been no notes/minutes taken during the meeting:
>> 
>> https://wiki.eclipse.org/Planning_Council/April_05_2017
>> 
> 
> -- 
> Wayne Beaton
> @waynebeaton
> The Eclipse Foundation
> ___
> 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

[cross-project-issues-dev] [aeri] Maintenance break on Thursday, March 9th, 9-11 AM

[Marcel Bruch]

Greetings cross-projects,

tomorrow, Thursday, around 10:00 AM EST / 4:00 PM CET, we'll change AERI’s user 
authentication to use Eclipse OAuth. The old browser-authentication will be 
turned off around 10:30 AM. During this transition you may have to enter your 
credentials twice: First time in the browser password dialog and the second 
time on the Eclipse login website.


If you have any trouble logging in after this update, please file a bug report 
at [1].

Marcel



[1] https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EPP
___
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] [aeri] New Problems first seen in Eclipse 4.7.x / Oxygen by Projects

[Marcel Bruch]

Greetings cross-project-issues,


just a short reminder: In case you reviewed an item from the list above, please 
make use one of the quick actions and close them as fixed, log message or 
whatever you think is appropriate. It just needs two clicks and helps us to 
keep the lists of errors to review short.

Thank you!
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] [aeri] New Problems first seen in Eclipse 4.7.x / Oxygen by Projects

[Marcel Bruch]

Good Morning Andrey,

> whoever is responsible for this (Marcel?):

Yes, I am.

> (not always accurate assignment to the projects, but bugs are real)


Please file a bug report and reference a few sample problems you think aeri 
could have done a better job. I’ll investigate those and see how we can improve 
the automated project assignments.


> Can we get exact this digest not on a monthly, but on a weekly base?

I hesitate to send this digest as a weekly digest to cross-projects b/c weekly 
may be too frequent for too many people on this list.

But there are alternatives:
Alternative #1: every project can set up its own specific Oxygen digests and 
send it to its mailing list.
Alternative #2: I can set up (a copy of) this digest as weekly digest. But 
instead of sending it to cross-projects-issues it, individuals can sign up for 
them on their own.

If anyone else is interested in receiving this digest on a weekly basis, please 
let me know.


Thank you and cheers
Marcel



> On 05 Jan 2017, at 22:15, Andrey Loskutov  wrote:
> 
> Hi,
> 
> whoever is responsible for this (Marcel?): great compilation (not always 
> accurate assignment to the projects, but bugs are real).
> 
> Is there is a bugzilla component to report enhancements for error reporting? 
> I haven't found "aeri" nowhere on eclipse bugzilla.
> 
> Can we get exact this digest not on a monthly, but on a weekly base?
> 
> Am 01.01.2017 um 10:04 schrieb Error Reports Bot:
>> Greetings cross-projects-issues,
>> 
>> this is the monthly overview of the TOP 10 open problems by project,
>> detected for Oxygen / Eclipse 4.7. All issues on this list have been
>> reported the *first time* for Oxygen and thus are likely *new* problems
>> introduced during the Oxygen milestones. Maybe we can triage them before
>> they get released.
> 
> -- 
> Kind regards,
> Andrey Loskutov
> 
> http://google.com/+AndreyLoskutov
> ___
> 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

[cross-project-issues-dev] [aeri] Update on Reporter Email Notifications

[Marcel Bruch]

Greetings cross-project-issues,

I’d like to inform you about a change on how AERI informs reporters about 
updates on the errors they reported. 

Starting from today, AERI will track changes to a problem’s status, resolution, 
bug, and custom resolution message and send emails to all reporters (of that 
problem) when one of these fields changed within the last 24 hours. 
This is a slight change compared to earlier versions, where we only send emails 
whenever a new bug was created for a problem. But we noticed that users do not 
get the feedback when their problems were actually fixed (because they do not 
have a bugzilla account and cannot CC to the bug report). This change aims to 
fix this gap.


Please let me know if you have any concerns with this change.


Cheers,
Marcel
-- 
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] [aeri] Change to how clients decide which error reports to send

[Marcel Bruch]

> On 21 Oct 2016, at 16:37, Gunnar Wagenknecht <gun...@wagenknecht.org> wrote:
> 
> Thanks Marcel!
> 
> Comments inline...
> 
>> On 21 Oct 2016, at 16:27, Marcel Bruch <marcel.br...@codetrails.com 
>> <mailto:marcel.br...@codetrails.com>> wrote:
>>> - what is a reporter id?
>> 
>> A standard UUID. We generate it once per user-home. We use that information 
>> to allow searches like “Give me all error reports ±5 minutes around this 
>> error report” or to collect how many users actually hit a problem (to assess 
>> its severity) etc.
> 
> Which is a nice metric. I'm wondering if it is as relevant as how ofter the 
> same error has been hit (regardless of user count).

The absolute number of all occurrences may be misleading if caused by just a 
single client.
Having both counts is probably what you’d like to see but this may cause a lot 
more traffic (if implemented naively) 


> 
>>> - is the reporter id an "opt-in”?
>> 
>> Yes and no. You opt in to send error reports w/ a uuid when you enable AERI 
>> (announced and implemented so from day one).
> 
> So it is  opt-in. I don't see any issues then.

OK, thanks for your assessment.
I’ll still wait (a week or so) for anyone vetoing before I start implementing 
that.

> 
>> FWIW, there is a change in progress that allows users to generate a fresh 
>> UUID on every eclipse startup.
> 
> off-topic, but doesn't that make the metric mentioned above impossible?

Yes, that’s why it should not be the default. But we can recognize such a 
session UUID and do not count them.

Marcel

> 
> -Gunnar
> 
> 
> 
> -- 
> Gunnar Wagenknecht
> gun...@wagenknecht.org <mailto:gun...@wagenknecht.org>, http://guw.io/ 
> <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] [aeri] Change to how clients decide which error reports to send

[Marcel Bruch]

> On 21 Oct 2016, at 15:28, Gunnar Wagenknecht <gun...@wagenknecht.org> wrote:
> 
> Hi Marcel,
> 
>> On 21 Oct 2016, at 12:24, Marcel Bruch <marcel.br...@codetrails.com 
>> <mailto:marcel.br...@codetrails.com>> wrote:
>> I’m looking for your input on the second part: whether sending the 
>> fingerprint of an error report to eclipse.org <http://eclipse.org/> before 
>> the user explicitly agrees to send the error itself is considered a privacy 
>> issue. My personal take is that the fingerprint itself does not contain any 
>> reasonable private information. However, under some conditions committers 
>> may be able to “see” which errors a user hits on his machine even if he does 
>> not send the error report ( IFF we'd send the reporter id along with the 
>> fingerprint or would track the reporter’s IP address - which we do not do!).
> 
> I find the last sentence confusing. :)
> 
> Can you clarify:
> - what is a reporter id?

A standard UUID. We generate it once per user-home. We use that information to 
allow searches like “Give me all error reports ±5 minutes around this error 
report” or to collect how many users actually hit a problem (to assess its 
severity) etc.

> - how is it related to the proposal, i.e. checking for known error 
> information as fingerprints?

I used this to illustrate when (I think) sending a fingerprint may reveal some 
information about the user.

> - why is it necessary for the proposal?

This is not required. It was more an example to illustrate when sending a 
fingerprint may reveal something about the reporter. The question is, whether 
this pair <reporter-id, error-fingerprint> is considered sensitive already.

> - is the reporter id an "opt-in”?

Yes and no. You opt in to send error reports w/ a uuid when you enable AERI 
(announced and implemented so from day one).

FWIW, there is a change in progress that allows users to generate a fresh UUID 
on every eclipse startup.


Does that answer all your questions?



> 
> Thanks!
> 
> -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

-- 
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

[cross-project-issues-dev] [aeri] Change to how clients decide which error reports to send

[Marcel Bruch]

Dear cross-project-issues,


we are currently investigating new approaches how to reduce the traffic AERI 
causes. One feature of AERI is to check a local database whether an error that 
was just logged is relevant to eclipse.org <http://eclipse.org/>, or should be 
ignored, or needs additional information etc. Based on that information the 
user gets different popups (or non in case it should be ignored).

The problem with the current approach is that it, in the meanwhile, causes 
several TB of traffic per month. This traffic is currently distributed over the 
eclipse mirrors so it’s not directly affecting download.eclipse.org 
<http://download.eclipse.org/> but IMHO its something that should be changed.

An alternative approach would be to replace the local problems database by a 
REST API where client’s can send a fingerprint to and get the same information 
directly from the server. The results may also be cached to limit/reduce 
further requests to the server. We estimate that this would reduce the traffic 
(TB) by an order of magnitude. 

The downside of such an approach would be that (i) we would see many more HTTPS 
requests to dev.eclipse.org/recommenders <http://dev.eclipse.org/recommenders> 
and (ii) that sending a fingerprint to eclipse.org <http://eclipse.org/> may be 
considered as a privacy issue by some.

The former is something we need to evaluate and discuss with webmaster(s). This 
process has already started.

I’m looking for your input on the second part: whether sending the fingerprint 
of an error report to eclipse.org <http://eclipse.org/> before the user 
explicitly agrees to send the error itself is considered a privacy issue. My 
personal take is that the fingerprint itself does not contain any reasonable 
private information. However, under some conditions committers may be able to 
“see” which errors a user hits on his machine even if he does not send the 
error report ( IFF we'd send the reporter id along with the fingerprint or 
would track the reporter’s IP address - which we do not do!).


Would you (better: who would) consider sending a fingerprint w/o explicit user 
confirmation as a privacy issue?



Thank you for your feedback
Marcel



-- 
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] [AERI] Using JVMTI to collect local variables in error reports

[Marcel Bruch]

Thank you for your input Sam.

> On 04 Oct 2016, at 18:28, Sam Davis  wrote:
> 
> One thing that immediately comes to mind is that local variables may contain 
> passwords.

True. That might happen.

> I think we would, at minimum, need a way for the user to see all of the 
> values they are sharing before sharing them, and it would have to be clear to 
> users when they enable this feature that they are putting their passwords at 
> risk.

Yes, something along these lines should be stated somewhere. We may add 
additional checks for special variable names like user username, pass, password 
and warn the user if variables with these names are found.


> I wonder if it would be useful to replace the values of string variables with 
> a non-reversible hash.

No, I guess that a fair share of all problems are caused by some “invalid” or 
“unexpected" strings. Hashing them will make this feature useless in (too) many 
cases (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

[cross-project-issues-dev] [AERI] Using JVMTI to collect local variables in error reports

[Marcel Bruch]

Greetings cross-projects,

I’d like to post a preliminary plan to this list to see if it will raise any 
concerns by the community.

As mentioned in a previous post, some automated error reports are hard to 
triage b/c they lack the (values of the) local variables that lead to an error. 
We did some research and figured out that we can enrich error reports with the 
values of all available local variables in each stack trace element by 
attaching a JVMTI agent to the Eclipse.

Our first experiments were quite promising and I’d like to make this feature 
available at least in the Eclipse IDE for Committers Package in Oxygen or (if 
it works properly) in Neon.3 time frame. Certainly this feature has some 
privacy and performance aspects to consider. W/o going into the technical 
details, we plan to enable the agent only on explicit user request and send the 
actual local variable values along with the error reports only if the user 
actually want’s to share them.


Does anyone on this list have any other concerns or constraints to 
address/consider when attaching a JVMTI agent to the eclipse process?

Thanks in advance,
Marcel



-- 
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

[cross-project-issues-dev] JVMTI & Automated Error Reporting

[Marcel Bruch]

* I'm cross-posting this to cross-project-issues-dev, epp-dev, and ide-dev 
hoping to reach out to the right people on these lists* 

Greetings Eclipse committers,

I got the feedback from some committers that triaging automated error reports 
w/o knowing the actual values of the local variables can be cumbersome. I thus 
started to look for a solution to this problem. 

One promising solution could be to register an agent (written in C) that uses 
the JVMTI interface to inspect the current stack frames and save all local 
variables whenever an exception is thrown. This information then could be made 
available in an error report or IStatus object.



My problem is that I don’t know anything about JVMTI nor have any experience 
writing VM agents in C nor building these agents for the common OS (Mac, Win, 
Linux). I wonder if there is anyone on this list who has this particular 
knowledge (or knows someone who has) and can help with this. 

If so, please let me know. I think it would be a tremendous improvement to 
Eclipse (not just Automated Error Reporting if the values would be logged along 
with the IStatus object) and help us to save hours of debugging.


Thanks in advance,
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] Eclipse for Committers

[Marcel Bruch]

> On 07 Sep 2016, at 07:55, Mickael Istria  wrote:
> If I'm not mistaken, the "for committers" being a subset of the "for 
> RCP/RAP", merging them would just mean removing the "for Committers”.

-1 for merging.

The committers package has different defaults - for instance it reports UI 
freezes by default. I’d also like to add a memory analyzer for OOMEs. Those 
items should not be in the standard RCP/RAP or Java package.

___
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] [aeri] Introducing (Custom) Error Report Processors

[Marcel Bruch]

Dear cross-projects,

the upcoming version of AERI will allow to run client-side analyses before an 
error report is send. 

For example, when a ClassNotFoundException is logged, AERI will run an analyzer 
that
tries to parse the class name from the exception’s error message, 
search for all bundles that export that class (i.e., the containing package) 
and 
check which bundles and packages the failing bundle was wired to.
The results of these analyses are added to the error report as "auxiliary 
information” automatically (requires user consent).

The Buildship team requested a means to add the Gradle version to error reports 
that mention Buildship somewhere. The Oomph team asked for means to run special 
analysis for FileNotFoundExceptions to detect whether these errors may be 
caused by an eager antivirus scanner. Both can be implemented using this API.

AERI will provide some "common processors” that add
all system properties,
all user preferences,
all installed bundles, resolution status, and wiring information,
all installed features + bundles with id, name, and version information,
to an error report on demand. We may also take this a step further to allow 
users to attach screenshots or code snippets to an error report.



The analyzers will be added to the review dialog as outlined below and can be 
de/activated in one click. The server can also demand auxiliary information 
which will be automatically added to the report (after user consent):
 


Every project will be able to register their own client-side analyses via an 
extension point. The exact details are not yet settled but I’d like to inform 
cross-projects early in the process to gather your requirements. If you have a 
requirement or feature request, please let me/us know in bug 496656 [1].

Thank you,
Marcel



[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=496656





-- 
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

[cross-project-issues-dev] Bugzilla Shows Internal Error on Create Bug

[Marcel Bruch]

Hi Webmasters,

I just noticed that Bugzilla gives me 500 Internal Error on 
https://bugs.eclipse.org/bugs/enter_bug.cgi 
.

Gerrit seems to be down as well.


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] [aeri] How To Automatically Create Bug Reports from your Error Reports

[Marcel Bruch]

There is nothing yet that allows a normal user to reopen a problem. There are 
other means like auto actions that can reopen a problem as soon as a new 
incident arrives that shows an already closed error still exists in a newer 
version of Buildship. See [1] for an example.

However, we (the Architecture Council, Mike, Wayne, Janet and me) discussed 
whether could give normal users anonymized read access to error reports and 
also allow them to create bug reports from them. All agreed that (given we do a 
proper anonymization), there is no reason why we should not allow users to 
create bug reports.

There is, however, the risk of having users blindly clicking on “Create Bug 
Report” from their submissions page when it becomes too easy. We should require 
(anonymous) users to provide little more content manually and put a minimum 
hurdle in place so that we do not get flooded.

We may also allow users to reopen a bug report with a comment - but I’m not 
sure this is a great idea.

Instead, we could allow users to “request reopening” and put this into 
(weekly/daily) email digests if you like.

We have many options. But there is currently nothing implemented that fully 
satisfies your need. Let’s discuss what you need and see where we go/end up 
with...






[1] https://blog.ctrlflow.com/hidden-gems-auto-reopening-problems/ 
<https://blog.ctrlflow.com/hidden-gems-auto-reopening-problems/>



> On 27 Jul 2016, at 12:28, Donát Csikós <csdo...@gmail.com> wrote:
> 
> I'm just trying to understand the workflow here. Let's say as an
> Eclipse user I enconunter an exception and I report it via AERI. For
> some cases I might get the response that this issues was resolved as
> invalid (no bug reports involved). Now, what if I know it is not true
> and I have an example exhibiting the problem. Can update the report or
> at least send my notes to the committers via AERI in an easy way?
> 
> 2016-07-27 12:00 GMT+02:00 Marcel Bruch <marcel.br...@codetrails.com>:
>> At the moment, they would have to put comment on / reopen the bug in
>> Bugzilla.
>> 
>> Would you like to have something "more interactive” or a different behavior?
>> If so, let me know what you would like to see.
>> 
>> FWIW,
>> AERI can (in general) reopen bugs in Bugzilla.
>> 
>> Cheers,
>> Marcel
>> 
>> 
>> On 27 Jul 2016, at 11:53, Donát Csikós <csdo...@gmail.com> wrote:
>> 
>> Hi Marcel,
>> 
>> Just a quick question: what if a reviewer incorreclty closes a report?
>> Is there a way for a reporter to reopen it if they are unhappy with
>> the resolution?
>> Cheers,
>> 
>> 
>> --
>> Donát Csikós
>> Software Engineer
>> Gradle GmbH
>> Firmensitz: Manteuffelstr. 60, 10999 Berlin, Germany
>> Registergericht: Amtsgericht Charlottenburg, HRB 162310
>> Geschäftsführer: Regine Dockter
>> T. +49-30-609886880
>> W. www.gradle.org
>> 
>> 2016-07-22 11:29 GMT+02:00 Marcel Bruch <marcel.br...@codetrails.com>:
>> 
>> Greetings Cross-Projects,
>> 
>> a question that was raised by several committers (and I think might be
>> relevant to some of you as well) was, how to configure AERI to automatically
>> create Bugzillas from your error reports. I published a short blog post
>> describing how projects can configure this behavior via an automated action
>> here [1].
>> 
>> In case you have any further question or need assistance on setting this up,
>> please do not hesitate to contact me...
>> 
>> Cheers,
>> Marcel
>> 
>> 
>> [1]
>> https://blog.ctrlflow.com/hidden-gems-automatically-create-bugs-error-reports/
>> 
>> 
>> 
>> ___
>> 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
>> 
>> 
>> _

Re: [cross-project-issues-dev] [aeri] How To Automatically Create Bug Reports from your Error Reports

[Marcel Bruch]

At the moment, they would have to put comment on / reopen the bug in Bugzilla. 

Would you like to have something "more interactive” or a different behavior?
If so, let me know what you would like to see.

FWIW,
AERI can (in general) reopen bugs in Bugzilla.

Cheers,
Marcel


> On 27 Jul 2016, at 11:53, Donát Csikós <csdo...@gmail.com> wrote:
> 
> Hi Marcel,
> 
> Just a quick question: what if a reviewer incorreclty closes a report?
> Is there a way for a reporter to reopen it if they are unhappy with
> the resolution?
> Cheers,
> 
> 
> -- 
> Donát Csikós
> Software Engineer
> Gradle GmbH
> Firmensitz: Manteuffelstr. 60, 10999 Berlin, Germany
> Registergericht: Amtsgericht Charlottenburg, HRB 162310
> Geschäftsführer: Regine Dockter
> T. +49-30-609886880
> W. www.gradle.org
> 
> 2016-07-22 11:29 GMT+02:00 Marcel Bruch <marcel.br...@codetrails.com>:
>> Greetings Cross-Projects,
>> 
>> a question that was raised by several committers (and I think might be
>> relevant to some of you as well) was, how to configure AERI to automatically
>> create Bugzillas from your error reports. I published a short blog post
>> describing how projects can configure this behavior via an automated action
>> here [1].
>> 
>> In case you have any further question or need assistance on setting this up,
>> please do not hesitate to contact me...
>> 
>> Cheers,
>> Marcel
>> 
>> 
>> [1]
>> https://blog.ctrlflow.com/hidden-gems-automatically-create-bugs-error-reports/
>> 
>> 
>> 
>> ___
>> 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

[cross-project-issues-dev] [aeri] How To Automatically Create Bug Reports from your Error Reports

[Marcel Bruch]

Greetings Cross-Projects,

a question that was raised by several committers (and I think might be relevant 
to some of you as well) was, how to configure AERI to automatically create 
Bugzillas from your error reports. I published a short blog post describing how 
projects can configure this behavior via an automated action here [1].

In case you have any further question or need assistance on setting this up, 
please do not hesitate to contact me...

Cheers,
Marcel


[1] 
https://blog.ctrlflow.com/hidden-gems-automatically-create-bugs-error-reports/ 


___
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] [aeri] Introducing project dashboards

[Marcel Bruch]

Hi Jesse, Jay Jay,

> On 21 Jul 2016, at 01:58, Jay Jay Billings  wrote:
> 
> Is this really every project?


Well, every project may have been a bad phrase. It’s all project’s 
listed/configured in AERI and that received error reports from the IDE error 
reporting.

Since most science projects are not deployed in the IDE (I assume), there are 
not many error reports for them.
Jetty is a bit different but not really an IDE plugin. The error reports in 
there do probably not make too much sense for Jetty.

FWIW, 
science and locationtech projects could use AERI as well. We have appenders for 
Logback and can quickly implement others as well. If there is interest, let me 
know.

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

[cross-project-issues-dev] [aeri] Introducing project dashboards

[Marcel Bruch]

Greetings cross-projects,

I’d like to announce the availability of project dashboards for all Eclipse 
projects. Dashboards provide you a quick overview about your project’s key 
metrics and problem queries. See the EPP Marketplace project dashboard [1] for 
an example. A detailed description of the dashboard feature and guidelines how 
to customize the charts is available at [2].


In case you have any questions about using dashboards or feature requests, 
please let me know.

Cheers,
Marcel


[1] 
https://dev.eclipse.org/recommenders/committers/aeri/v2/#!/projects/54bc9f06bee886e008a60d1b/dashboard
 

[2] https://blog.ctrlflow.com/project-dashboards/ 
___
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] Code Recommenders participates in Oxygen +3

[Marcel Bruch]

Hi,

Code Recommenders will be participating in the Eclipse Oxygen
Simultaneous release with its usual offset of +3.

According to our current plans, we will contribute Code Recommenders
2.5.0 [1].

Best wishes,

Marcel

[1]
>
___
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] [aeri] Providing (anonymized) access to error reports for contributors

[Marcel Bruch]

Dear cross-projects,

several committers asked whether we could give *contributors* access to error 
reports and let them review, triage and fix problems spotted in Eclipse in 
order to distribute the workload better.

Contributors cannot get full access to all reports but providing an *anonymized 
view*  (that does not contain potentially sensitive information like reporter 
names, email addresses, ids, comments, error messages etc.) seems to acceptable 
and a viable alternative.


I created an example for such a public view for your review here:

Reviewer’s view:
https://dev.eclipse.org/recommenders/committers/aeri/v2/#!/problems/552bd8f4e4b026254ee03b58
 


Reporter’s view:
https://dev.eclipse.org/recommenders/community/aeri/v2/#!/problems/552bd8f4e4b026254ee03b58
 



Please let me know if you have any concerns with that proposal. The 
Foundation's Legal and the Architecture Council approved the general idea but 
we’d like to bring this to your attention early in the process and before 
announcing this to the public. If no issues are raised, I’ll modify the digest 
emails to contain links to the public problem views which adds the option to 
create bug reports from them.


Thank you.
Marcel


P.S.:

Side Note: Mars.2 contained 30% less errors than Mars.0. Let’s take these 
numbers further down in Neon...



Source 


___
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] List of active problem by code location

[Marcel Bruch]

Greetings cross-project-issues-dev,

I got a request to generate a list of problems sorted by the stack trace 
element throwing an exception. I found this way of representing the error 
reports insightful and thought it might interesting for others as well. The 
list contains (a subset of) all problems that have been observed for Eclipse 
4.5.2 and later and can be downloaded here [1].


Cheers,
Marcel


[1] 
https://dev.eclipse.org/recommenders/community/downloads/active-problems-in-eclipse-code.xlsx
___
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] 1.595 unresolved issues in Neon M7 and later

[Marcel Bruch]

Greetings cross-project,

I just run a few queries against the error reporting database and recognized 
that there are ~1600 open problems reported for Eclipse Build 4.6.0.I20160301 
and later. Some of these are ArrayOutOfBoundsExceptions, ArrayStoreExceptions, 
NullPointerExceptions etc. and might be low-hanging-fruits to fix during RCs.


The list of all problems can be found in [1]. To search for your projects 
simply add a "project search clause" as shown in [2].


Marcel


[1] http://eclip.se/9Q
[2] http://eclip.se/9R

___
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] [aeri] Updating error reporting server over the weekend

[Marcel Bruch]

Greetings cross-projects,

I’m currently installing a major update of the error reporting server.

The old system is currently turned off; the urls are redirecting to the new 
system. The redirects are rather coarse-grained but will be refined some time 
next week. 

The new web ui is available at [1]. But the final urls may change when the 
migration is complete. I’m expecting the migration to be complete on Sunday. 
Completion notices, final links etc. will be posted to bug 491653 [2].

Marcel


[1] https://dev.eclipse.org/recommenders/committers/aeri/v2/#!/problems/? 

[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=491653 
___
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] [aeri] Custom email digests per development streams

[Marcel Bruch]

Greetings cross-projects,

as of today projects can have individual alerts per "development streams“, 
i.e., your weekly digests can specify required version ranges for bundles, 
products, and operating systems as needed.

With that you can separate your alerts to match all problems that occur in, 
say, org.eclipse.yourbundlenamespace in versions [2.3-3.0] (Neon development) 
and org.eclipse.yourbundlenamespace in versions [,2.3)  for everything else 
(e.g. Mars). You may also filter based on the Eclipse build Id like [4.5.1,) or 
OS like macosx in version [11.11,].

There are more filtering capabilities available. If you are interested in 
setting up specialized filters, please file a bug .

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] Stats on OS being used

[Marcel Bruch]

Given Eike’s numbers, Mac users make 7 % of the downloads. 
In the last 90 days they 'contributed' 15% of all error reports.
Not sure what you can take away from these numbers, though… :-)




[1] http://eclip.se/6b 
<https://dev.eclipse.org/recommenders/committers/dashboard/#/visualize/edit/Incidents-by-OS?_g=(refreshInterval:(display:Off,pause:!f,section:0,value:0),time:(from:now-90d,mode:quick,to:now))&_a=(filters:!(),linked:!f,query:(query_string:(analyze_wildcard:!t,query:'*')),vis:(aggs:!((id:'1',params:(),schema:metric,type:count),(id:'2',params:(field:osgiOs,order:desc,orderBy:'1',size:5),schema:segment,type:terms)),listeners:(),params:(addLegend:!t,addTooltip:!t,isDonut:!t,shareYAxis:!t),type:pie))>


> Am 18.11.2015 um 17:24 schrieb Eike Stepper <step...@esc-net.de>:
> 
> This is what I figured for Mars (incl. milestones):
> 
> win32: 9,000,000
> macos: 740,000
> linux: 800,000
> 
> Cheers
> /Eike
> 
> 
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
> 
> 
> 
> Am 18.11.2015 um 15:56 schrieb Denis Roy:
>> I do -- and so do you!
>> 
>> https://dev.eclipse.org/committers/committertools/stats.php
>> 
>> Start with a quary against download.eclipse.org and use file pattern:
>> 
>> /technology/epp/%mars
>> 
>> That should get you going.
>> 
>> Denis
>> 
>> 
>> On 11/18/2015 09:52 AM, Pascal Rapicault wrote:
>>> Since there are discussions on improving SWT for specific platforms, I
>>> think it would be interesting to see a rough percentage of the downloads
>>> per platform.
>>> Denis, would you have access to this?
>>> 
>>> Thanks,
>>> 
>>> Pascal
>> ___
>> 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

[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 
> <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] AERI conclusions after 3 weeks of Mars.1

[Marcel Bruch]

Ed, Torkild,

the number of users certainly affect the total number of error reports send to 
eclipse.org <http://eclipse.org/>. But it should not have such a big effect on 
the number problems we see for the first time.

In addition, the number of reporters per week did not change significantly:




The duplicate detection in the meantime is also quite generous in what is 
considers a „similar“ problem. FWIW, these problems do not include error 
reports containing 3rd party plugins nor ui freezes. Just plain ‚normal‘ 
problems like NullPointerExceptions in pure eclipse traces [1].



https://dev.eclipse.org/recommenders/committers/confess/#/problems/?kinds=NORMAL=false=IGNORE=NullPointerException=4.5.1=overview=0=500=modifiedOn,desc
 
<https://dev.eclipse.org/recommenders/committers/confess/#/problems/?kinds=NORMAL=false=IGNORE=NullPointerException=4.5.1=overview=0=500=modifiedOn,desc>



> Am 25.10.2015 um 13:16 schrieb Torkild Ulvøy Resheim <torki...@gmail.com>:
> 
> Hi Marcel, Ed
> 
> I agree with Ed here. I believe this can be related to the number of users 
> and adopters typically not building on top of Eclipse before the SR1.
> 
> Best regards,
> Torkild
>> 25. okt. 2015 kl. 13.10 skrev Ed Willink <e...@willink.me.uk>:
>> 
>> HI Marcel
>> 
>> Disappointing, but there might be a simple explanation - different numbers 
>> of users.
>> 
>> Some users prefer to wait for a .1/SR1 before migrating.
>> 
>> Some users dependent on third party add-ons / rebranding may not get to 
>> migrate until Mars.1
>> 
>> You cannot know the number of actual users, but you could normalize to the 
>> number of reporting users.
>> 
>>   Regards
>> 
>>   Ed Willink
>> ___
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Upcoming Changes to Mars.1 Error Report Digests

[Marcel Bruch]

Greetings Eclipse project leaders.

For Mars.0 we roughly collected one million error reports [1,2]. But with the 
advent of Mars.1 there will be multiple versions of the same bundles be 
available, which makes it hard to track which bugs have really been fixed and 
which ones still exist in the latest versions of our software. I’ve to admit 
that I hoped to receive less reports and to see bugs getting fixed quicker or 
to see projects marking error reports they don’t want to handle as wontfix. But 
fixing takes time and marking issues as wontfix turned out to be a too large 
overhead.

Given these observations I’d like to change the weekly digests to only report 
issues that occurred on Mars.1 or later, i.e., I’ll implement a filtering based 
on the Eclipse build-id and only add those reports to the digest that occurred 
on a current Eclipse version. I plan to take that change live by the end of 
October. If you (i.e, your project) still wants to receive error reports for 
older versions of Eclipse, please let me know. We can make that happen.

If you are looking for a more fine-grained control, please post your 
requirements to bug 47112 [3].
If you are interested in face-to-face discussions: There will be a BoF at 
EclipseCon Europe on Tuesday evening 20:00 [4] for discussing the future of 
automated error reporting.

Best regards,
Marcel

[1] 
https://dev.eclipse.org/recommenders/committers/dashboard/#/dashboard/Incidents 

[2] 
https://dev.eclipse.org/recommenders/committers/dashboard/#/dashboard/Problems 

[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=471112 

[4] 
https://www.eclipsecon.org/europe2015/bof-session/automated-error-reporting-how-proceed-eclipse-neon
 
___
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] Eclipse Mars 1 RC4 issue with Buildship / workspace prompt

[Marcel Bruch]

I commented on the linked bug and currently strongly disagree with David’s 
opinion.


Short: 
If every Eclipse user using the Java, Java EE, or RCP/RAP EPP Package is 
affected by this, then its no doubt a blocker. 
Then, I vote for a rebuild (and if necessary for postponing the release if 
necessary - just to make clear how strong I feel about it).

If not every Java, Java EE, or RCP/RAP EPP Package user is affected by it, I’d 
like to understand when this issue occurs - and when it doesn’t.

Follow-ups in Bugzilla.
Marcel




> Am 23.09.2015 um 09:27 schrieb Mickael Istria <mist...@redhat.com>:
> 
> My favourite NetBeans troll couldn't miss this opportunity 
> https://twitter.com/ehsavoie/status/646583406176960512 
> <https://twitter.com/ehsavoie/status/646583406176960512>
> Tha and my regular chats with various IDE users (I spend a few hours monthly 
> trying to convince IntelliJ and NetBeans users that Eclipse IDE isn't that 
> bad)  make me feel that this issue is "reputation busting embarrassing".  At 
> least, I don't know how I could keep on evangelizing about Eclipse IDE if our 
> community is OK to ship a major bug in a high visible project to its users.
> The bar of quality expectation has raised, IntelliJ and NetBeans are doing a 
> great job, shipping applications that seem mostly bug-free. If we want 
> Eclipse IDE to stay relevant we cannot ship applications with a critical bug.
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com/> - My Tweets 
> <http://twitter.com/mickaelistria>___
> 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

[cross-project-issues-dev] New Error Reporting Dashboards & BoF EclipseCon

[Marcel Bruch]

Greetings cross-projects,

I spent some time to visualize how the system developed in the past months in 
terms of number of users, number of new errors, numbers of fixed bugs etc. 
Therefore I reworked the dashboard to visualize these metrics more accurately. 

The dashboard has been split into two pages: 
* one page [1] that visualizes some statistics of the reported incidents (i.e., 
the error reports users send from within Eclipse) and 
* another page [2] that details about the problems (i.e, the potential bug 
clusters created after duplicate detection).

These report provide answers about how many new problems we see per day, how 
many reporters (Eclipse users) use the system to report errors, how many bugs 
have been fixed and by which projects and many things more.

As usual: 
Since most values are fully automated data aggregations w/o any human user 
interactions: Please ask your personal statistician next to you before drawing 
any (potentially invalid) conclusions and starting to blame any project. Thank 
you.


Short announcement:
I’d like to host a BoF to discuss key findings from 12 months automated error 
reporting and how to continue with or improve automated error reports at 
EclipseCon in Ludwigsburg this year. I’ll try to get a slot on Tuesday evening. 
If you are interested, please let me know.


Thank you,
Marcel

[1] 
https://dev.eclipse.org/recommenders/committers/dashboard/?#/dashboard/Incidents
 

[2] 
https://dev.eclipse.org/recommenders/committers/dashboard/?#/dashboard/Problems 


___
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] [aeri] Introducing server-side-managed ignore lists for Mars.1

[Marcel Bruch]

Greetings cross-projects,


AERI Eclipse client got a couple of improvements - one  I’d like to draw your 
attention to: 

Status filters:

Status filters allow filtering of logged error statuses based on three criteria:

1. the plugin id,
2. the exception type, and
3. the status message.

Status filters thus can be used to declare classes error statuses  which should 
be ignored (like P2 errors caused by unreachable update sites or when P2 
proposes alternative upgrade paths etc.)


Below you find a set of filters I came up with that exclude log messages I 
frequently got notified about. As you see all three sections support * and $ 
(ends with) wildcards to match logged status objects. In case you have 
suggestions for further filters, please let me know.

  "ignoredStatuses": [
"org.eclipse.equinox.p2.*::",
"org.eclipse.epp.mpc.ui:java.io.IOException:",
"org.eclipse.epp.mpc.ui:java.net.SocketTimeoutException:",
"org.eclipse.oomph.setup.core:$org.apache.http.ConnectionClosedException:",
"org.eclipse.ui::Conflicting handlers for*",
"org.eclipse.jface:java.io.IOException:Unable to resolve plug-in*",
"org.eclipse.core.runtime::Invalid input url*",
"org.eclipse.core.filesystem::Could not move*",
"org.eclipse.core.filesystem::Could not delete*",
"org.eclipse.pde.core::The current target platform contains errors*"
  ],


Cheers,
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] [aeri] Skipping UI freeze reports caused by OSGI class loading for Mars.1?

[Marcel Bruch]

 Am 25.08.2015 um 16:29 schrieb Doug Schaefer dschae...@qnx.com:
 
 This has been a problem for many years. I’m not sure much can be done.
 Though there may be cases where whatever is triggering the plug-in loads
 could be moved to a background job. To help understand that, the logs
 would be interesting for those cases. How much of this is done by the
 platform UI? How much by sloppy code or old code? How much is unavoidable.
 
 It certainly annoys users and would be worth characterizing at least.

Martin asked for a few numbers about average durations of class loading ui 
freezes on Bugzilla.
The numbers, averages, median etc. have been published in bug 475755 [1].

Let me know what kind of characterization you are looking for. If possible I 
can try to come up with a statistic.

Cheers,
Marcel

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=475755 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=475755

___
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] [aeri] Skipping UI freeze reports caused by OSGI class loading for Mars.1?

[Marcel Bruch]

Dear cross-projects,

I’m currently investigating ui freeze reports. 
Many of those freezes are caused by loading classes or resources from zip files 
inside the UI thread.
I tend to believe that those UI freezes cannot be „fixed“ by loading classes 
in the background“ and also believe that these freezes are annoying for users 
as well.


If anyone actually cares for those ui freezes or anyone has some great 
recommendations how to deal with those freezes, let me know. 
Otherwise I’ll stop collecting ui freezes that contain at 
org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass“ and friends. 
This change would go live in Mars.1.

Discussions can take place in bug 475755 [3].

Cheers,
Marcel





[1] 
https://dev.eclipse.org/recommenders/committers/confess/#/problems/55dabf6ae4b0f0b83a6ed605/details
[2] 
https://dev.eclipse.org/recommenders/committers/confess/#/problems/55d80098e4b0f0b83a6eae77/details
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=475755



-- 
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] Code Recommenders Participation in Neon

[Marcel Bruch]

 Code Recommenders will participate with version 2.3.x.


offset +3
___
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] Code Recommenders Participation in Neon

[Marcel Bruch]

Code Recommenders will participate with version 2.3.x.

// do we still need these emails?
___
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

[Marcel Bruch]

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

[Marcel Bruch]

 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

[Marcel Bruch]

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

[Marcel Bruch]

 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

[Marcel Bruch]

 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

[Marcel Bruch]

 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

[cross-project-issues-dev] OAuth 2.0 Eclipse Services

[Marcel Bruch]

Greetings cross-projects,

for the error reporting I’d like to give committers/reporters the ability to 
store personal preferences and get access to the errors they sent in the past, 
current status of these problems etc. For that I need to authenticate users by 
email address. One (half-baked) idea is to allow users to register using some 
OAuth provider like Google, Github or - if supported - eclipse.org 
http://eclipse.org/.

My question is, does any eclipse project have OAuth working in their code base 
(plugin or server)?
Which libraries do you use and what else should we be aware of?

Thanks for pointers,
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

[Marcel Bruch]

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

[Marcel Bruch]

 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

[Marcel Bruch]

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

[Marcel Bruch]

 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

[cross-project-issues-dev] [AERI] Short Status Update

[Marcel Bruch]

Greetings cross-projects,

I’d like to give a short status update 3 weeks after the Mars release. 

It’s a bit of a surprise to me but we (only) receive ~7K error reports per day. 
This is roughly 6x more traffic than during the milestones. It looks like the 
various filters and caches in place work well enough. A fair share is caused by 
third-party plugins but most issues are still issues in the Eclipse codebase.

I also like to send a big Thank You! to the Eclipse Foundation admins: The 
error database download causes more traffic than I initially estimated but so 
far we did not see any network outage nor did webmasters threaten me with 
violence. Nevertheless, we will improve that for SR1...

We also had a serious proxy issue on Windows (as discussed before on this list) 
which has been resolved with the aid of an AERI user.

Some numbers:
Before the Mars release we had ~275 FIXED Bugzilla tickets created from 
incoming Milestone error reports. I’m happy to say, that in the meanwhile ~50 
more bugs have been marked as FIXED [2] and likely will be available in SR1. In 
the first two weeks we had ~10K new error reporters and I estimate this number 
is even bigger now.

If you are interested in more numbers before the release, you may find these 
slides interesting [1].


My personal perception is that AERI is making more and more friends in the 
Eclipse committer community but only a couple projects use it as extensively as 
I had hoped. For those committers who tried but do not use it regularly, I’d be 
happy to hear what you find disturbing and/or how to improve. For a list of 
open feature requests, see [3]. 


You may also consider sending weekly error report digests to your project’s dev 
mailing list instead to individual committers to share the workload.

Keep in mind: SR1 is not far away :-)


Cheers,
Marcel


[1] 
https://www.eclipsecon.org/france2015/sites/default/files/slides/2015-06%20-%20EclipseCon_0.pdf
 
https://www.eclipsecon.org/france2015/sites/default/files/slides/2015-06%20-%20EclipseCon_0.pdf
[2] http://eclip.se/4U http://eclip.se/4U (note: query shows ~10 bugs less 
when NOT logged in as committer)
[3] http://eclip.se/4W http://eclip.se/4V



-- 
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] Removing non related projects when triaging AERI issues

[Marcel Bruch]

Thanks Alexander, makes sense. Can you please create a bug we can use to track 
this request?

FWIW, we have extra logic in place for projects like Xtext (which is used by 
OCL, Papyrus and others) when one of their clients is on the stack, we’ll 
remove xtext from the list of projects. We could do the same for GEF.

If we should do the same for GEF, please also create a bug report and list the 
projects we should use for removal checks.

Thanks,
Marcel


 Am 19.06.2015 um 06:39 schrieb Alexander Nyßen nys...@itemis.de:
 
 Because GEF is contained in pretty much all the stack traces of its adopters 
 (GMF, Sirius, Papyrus and others) I find myself triaging several issues that 
 are actually not related to problems in GEF. That’s fine, I don’t want to 
 lament that GEF has a lot of adopters and of course I want to support them 
 all. However, I recently ran into cases were issues were indeed already 
 triaged (i.e. a bugzilla was created for a specific project), but the list of 
 projects was not adjusted. In order to reduce overhead, it would IMHO be a 
 good policy to remove other projects from an AERI issue in case triaging 
 leads to a bugzilla for a specific project (the projects list can easily be 
 edited during triaging, and non-related projects can simply be removed from 
 it).
 
 Cheers
 Alexander
 --
 Dr. Alexander Nyßen
 Dipl.-Inform.
 Principal Engineer
 
 Telefon: +49 (0) 231 / 98 60-202
 Telefax: +49 (0) 231 / 98 60-211
 Mobil: +49 (0) 151 /  17396743
 
 http://www.itemis.de http://www.itemis.de/
 alexander.nys...@itemis.de mailto:alexander.nys...@itemis.de
 
 itemis AG
 Am Brambusch 15-24
 44536 Lünen
 
 Rechtlicher Hinweis:
 
 Amtsgericht Dortmund, HRB 20621
 
 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
 Trompeter, Sebastian Neus
 
 Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
 Fiorentino
 
 
 
 ___
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] [ide-dev] Phasing in Error Reporting for Mars (was: Start collecting requests for Error Reporting v2)

[Marcel Bruch]

— Adding epp-dev to this discussion b/c the proposals below affect EPP packages 
— 

The amount of traffic is something no one can estimate yet. I think everyone 
feels a little bit uncomfortable with this situation. So here is a proposal I’d 
like to discuss publicly (although only a small subset of people may feel need 
to discuss this).


Markus (Knauer),
in case we’d need to disable error reporting because of too much traffic: is it 
possible for you to simply rebuild the packages with an additional preference? 
This preference would preconfigure the system to “don’t send error reports.

How quickly could we do that - in worst case?


Denis,
since JEE is the largest error reports provider, I can imagine to disable the 
error reporter for this package in the beginning. Disabling would mean that the 
user would have to go to the preferences page and enable it explicitly by 
changing a value in some combo box. 


Three options I’d feel comfortable with: 

1. The milquetoast option: Disable error reporting for JEE in the first days 
(via preferences as outlined above). If no outages occur, we can rebuild the 
JEE package and reenable it. We could also do the same for the Java package. 
With that we could slowly phase-in and see whether we can handle the traffic.

2. The daredevil option: Deactivate it in new EPP downloads as soon as we see 
that there is too much traffic. But then the sending clients are already out 
there...

3. I forgot option three. But I had one before I went to breakfast… Ah, here it 
is: The BOFH option: Use the firewall to block every, say, second access to the 
HTTP HEAD requests to the remote problems database. With that, create a 
controlled phasing in by selectively disabling half of the clients (randomly). 
Instead of blocking every second request, we may disable it for some hours of 
the days. Since this will disable the error reporter until restart we may 
temporarily disable the clients completely on the server-side w/o changing any 
EPP package.

What do you think?


 It appears to me that you didn't just write code; you've engineered a 
 solution.

Credits for this go to all people involved in various discussions over the past 
milestones and their feature requests. See bug 457115 [1] as one great example 
- but there are many more.



Denis, BTW:
can we get more bandwidth for dev.eclipse.org/recommenders? :-)


Marcel


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=457115

 On 12 Jun 2015, at 20:26, Denis Roy denis@eclipse.org wrote:
 
 It appears to me that you didn't just write code; you've engineered a 
 solution.
 
 No need for crossed fingers.  I think we're in good shape.  Beer will be on 
 me at EclipseCon.
 
 Have a nice weekend.
 
 Denis
 
 
 
 On 12/06/15 02:21 PM, Marcel Bruch wrote:
 Denis,
 
 there are four (4) + one (1) mechanisms in place that will / can limit the 
 traffic to dev.eclipse.org/recommenders:
 
 Level 1: A local, persistent, per-workspace history that remembers what was 
 send before. If an error is logged that has the same fingerprint as an 
 already sent report, it is skipped. This should prevent clients to send the 
 same error over and over again.
 
 Level 2: A “known errors database” that get’s downloaded from eclipse.org on 
 IDE startup. If an error is logged in the IDE which was marked as “ignored” 
 in the known-errors database, it won’t be send. No network traffic will 
 happen. The server-side generates this database on demand and set’s every 
 problem to ignore that was reported by more than 50 users.
 
 Level 3: The “emergency” power OFF switch [1]. On startup, we check whether 
 a certain system status URL is reachable. If that   fails, the system 
 deactivates the reporter until next restart of Eclipse.
 
 Level 4: If Eclipse is started with 
 ‑Dorg.eclipse.epp.logging.aeri.ui.skipReports=true, no errors will be sent. 
 EPP packages may add this into the eclipse.ini in worst case.
 
 Level 5: I’m not sure what exactly would happen if the firewall blocks 
 access the service. But I assume we catch every exception and log it 
 gracefully as a warning. So this looks like Level 5 to me.
 
 However, the traffic may still be large - especially in the first days. In 
 that case I’m happy to pull the plug via Option 3 or Level 4 by rebuilding 
 the EPP packages. Or 5 if you don’t see any other option. Or we start with 
 just one EPP (e.g. Committers and or Java) package for the release and add 
 more until we are sure it works. I think we have all options in your hands 
 to control it on various levels.
 
 
 Regarding Reporting to Bugzilla: Yes, the traffic goes to 
 dev.eclipse.org/recommenders/* If this server is shut down, nothing can ever 
 go to Bugzilla. 
 
 I hope I'll keep my account for a while… still crossing fingers, though.
 
 Best,
 Marcel
 
 
 [1] 
 https://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/tree/bundles/org.eclipse.epp.logging.aeri.ui/src/org/eclipse/epp/internal/logging/aeri/ui/log

Re: [cross-project-issues-dev] [ide-dev] Start collecting requests for Error Reporting v2

[Marcel Bruch]

I see your point. Having a cross-workspaces history was something we discussed 
lately but I had not enough time to think it through and implement it. The 
request was closed as won fix because there are several alternatives:

If 50 users reported the same error, it will be added to the remote error 
database as “ignorable log message” automatically.
On the server-ui, If you mark the problem as log message in the error 
reporter’s web ui, it will be added to the remote errors database as “ignorable 
log message” as well.
On the client-ui, If you check the “this is a log message” checkbox in the 
details dialog, we can use that info to add this problem to the “ignorable log 
message” list as well.
The latter hasn’t been implemented yet but since this is a server-side change, 
it can be implemented quickly. You may not want to wait for 50 other users, but 
you may be okay with option 2 or 3?


If you (or anyone else) thinks a cross-workspaces history is required, please 
reopen [1] and add yourself to cc. If a reasonable amount of committers think 
this is required, we can rethink the wontfix for SR1.


Thanks,
Marcel

https://bugs.eclipse.org/bugs/show_bug.cgi?id=468929 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=468929



 On 12 Jun 2015, at 20:54, Torkild Ulvøy Resheim torki...@gmail.com wrote:
 
 Hi Marcel,
 
 This is looking good. But I’m a bit concerned about “Level 1” - If you have a 
 dozen workspaces, I don’t think I’m the only one, you will still produce 
 excessive error reports. Also I do keep hitting the same error again and 
 again, but choose to not send (because I know the reason). However I’m pretty 
 sure I have reported it in the past. Anyway, the code I’m running is on Mylyn 
 snapshot builds, which I guess only a few is executing. Could that be the 
 reason why it’s not ignored?
 
 Best regards,
 Torkild
 12. jun. 2015 kl. 20.21 skrev Marcel Bruch marcel.br...@codetrails.com:
 
 Denis,
 
 there are four (4) + one (1) mechanisms in place that will / can limit the 
 traffic to dev.eclipse.org/recommenders:
 
 Level 1: A local, persistent, per-workspace history that remembers what was 
 send before. If an error is logged that has the same fingerprint as an 
 already sent report, it is skipped. This should prevent clients to send the 
 same error over and over again.
 
 Level 2: A “known errors database” that get’s downloaded from eclipse.org on 
 IDE startup. If an error is logged in the IDE which was marked as “ignored” 
 in the known-errors database, it won’t be send. No network traffic will 
 happen. The server-side generates this database on demand and set’s every 
 problem to ignore that was reported by more than 50 users.
 
 Level 3: The “emergency” power OFF switch [1]. On startup, we check whether 
 a certain system status URL is reachable. If that fails, the system 
 deactivates the reporter until next restart of Eclipse.
 
 Level 4: If Eclipse is started with 
 ‑Dorg.eclipse.epp.logging.aeri.ui.skipReports=true, no errors will be sent. 
 EPP packages may add this into the eclipse.ini in worst case.
 
 Level 5: I’m not sure what exactly would happen if the firewall blocks 
 access the service. But I assume we catch every exception and log it 
 gracefully as a warning. So this looks like Level 5 to me.
 
 However, the traffic may still be large - especially in the first days. In 
 that case I’m happy to pull the plug via Option 3 or Level 4 by rebuilding 
 the EPP packages. Or 5 if you don’t see any other option. Or we start with 
 just one EPP (e.g. Committers and or Java) package for the release and add 
 more until we are sure it works. I think we have all options in your hands 
 to control it on various levels.
 
 
 Regarding Reporting to Bugzilla: Yes, the traffic goes to 
 dev.eclipse.org/recommenders/* If this server is shut down, nothing can ever 
 go to Bugzilla.
 
 I hope I'll keep my account for a while… still crossing fingers, though.
 
 Best,
 Marcel
 
 
 [1] 
 https://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/tree/bundles/org.eclipse.epp.logging.aeri.ui/src/org/eclipse/epp/internal/logging/aeri/ui/log/CheckServerAvailabilityJob.java#n51
 
 
 On 12 Jun 2015, at 19:57, Denis Roy denis@eclipse.org wrote:
 
 
 
 On 06/12/2015 01:15 AM, Marcel Bruch wrote:
 We are now looking forward to the first two weeks of the Mars release
 and cross fingers that we don’t get flooded.
 
 Marcel,
 
 Do we have an OFF switch somewhere so that we can turn these things off 
 if we see we're going to get flooded?
 
 Have we...?
 Do you...?
 
 
 I have a big OFF switch called a firewall, but I'm not sure how that will 
 manifest itself in Eclipse if the error reporter cannot connect to its home 
 site.
 
 Also, just so I understand, the 1000's of daily reports  (which could 
 become 100,000's of daily reports on June 25) are all reports against the 
 recommenders server, right?  Not Bugzilla bugs, right? The latter could see 
 the OFF switch extended to your user account

Re: [cross-project-issues-dev] [ide-dev] Start collecting requests for Error Reporting v2

[Marcel Bruch]

 cost you a fortune in beer at EclipseCon


Two questions: 

1. Which one (EclipseCon) will you attend? 
2. How long does your short-term memory last?




 On 12 Jun 2015, at 15:03, Denis Roy denis@eclipse.org wrote:
 
 
 On 06/12/2015 01:15 AM, Marcel Bruch wrote:
 We are now looking forward to the first two weeks of the Mars release
 and cross fingers that we don’t get flooded.
 
 Marcel,
 
 Do we have an OFF switch somewhere so that we can turn these things off if we 
 see we're going to get flooded?
 
 I don't have much faith in your crossed fingers, and if we _do_ get flooded, 
 it's going to cost you a fortune in beer at EclipseCon.
 
 D.
 ___
 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] [ide-dev] Start collecting requests for Error Reporting v2

[Marcel Bruch]

 On 12 Jun 2015, at 15:03, Denis Roy denis@eclipse.org wrote:
 
 
 On 06/12/2015 01:15 AM, Marcel Bruch wrote:
 We are now looking forward to the first two weeks of the Mars release
 and cross fingers that we don’t get flooded.
 
 Marcel,
 
 Do we have an OFF switch somewhere so that we can turn these things off if we 
 see we're going to get flooded?

Have we...? 
Do you...?
















I have 
https://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/tree/bundles/org.eclipse.epp.logging.aeri.ui/src/org/eclipse/epp/internal/logging/aeri/ui/log/CheckServerAvailabilityJob.java#n51
 
https://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/tree/bundles/org.eclipse.epp.logging.aeri.ui/src/org/eclipse/epp/internal/logging/aeri/ui/log/CheckServerAvailabilityJob.java#n51


 I don't have much faith in your crossed fingers, and if we _do_ get flooded, 
 it's going to cost you a fortune in beer at EclipseCon.

If a head request to 
https://dev.eclipse.org/recommenders/community/confess/problems.zip 
https://dev.eclipse.org/recommenders/community/confess/problems.zip fails, 
the system deactivates the reporter for 24 hours. In theory. But who knows … 
I’m still crossing fingers… 

Marcel

 
 D.
 ___
 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] [ide-dev] Start collecting requests for Error Reporting v2

[Marcel Bruch]

Denis,

there are four (4) + one (1) mechanisms in place that will / can limit the 
traffic to dev.eclipse.org/recommenders:

Level 1: A local, persistent, per-workspace history that remembers what was 
send before. If an error is logged that has the same fingerprint as an already 
sent report, it is skipped. This should prevent clients to send the same error 
over and over again.

Level 2: A “known errors database” that get’s downloaded from eclipse.org on 
IDE startup. If an error is logged in the IDE which was marked as “ignored” in 
the known-errors database, it won’t be send. No network traffic will happen. 
The server-side generates this database on demand and set’s every problem to 
ignore that was reported by more than 50 users.

Level 3: The “emergency” power OFF switch [1]. On startup, we check whether a 
certain system status URL is reachable. If that fails, the system deactivates 
the reporter until next restart of Eclipse.

Level 4: If Eclipse is started with 
‑Dorg.eclipse.epp.logging.aeri.ui.skipReports=true, no errors will be sent. EPP 
packages may add this into the eclipse.ini in worst case.

Level 5: I’m not sure what exactly would happen if the firewall blocks access 
the service. But I assume we catch every exception and log it gracefully as a 
warning. So this looks like Level 5 to me.

However, the traffic may still be large - especially in the first days. In that 
case I’m happy to pull the plug via Option 3 or Level 4 by rebuilding the EPP 
packages. Or 5 if you don’t see any other option. Or we start with just one EPP 
(e.g. Committers and or Java) package for the release and add more until we are 
sure it works. I think we have all options in your hands to control it on 
various levels.


Regarding Reporting to Bugzilla: Yes, the traffic goes to 
dev.eclipse.org/recommenders/* http://dev.eclipse.org/recommenders/* If this 
server is shut down, nothing can ever go to Bugzilla. 

I hope I'll keep my account for a while… still crossing fingers, though.

Best,
Marcel


[1] 
https://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/tree/bundles/org.eclipse.epp.logging.aeri.ui/src/org/eclipse/epp/internal/logging/aeri/ui/log/CheckServerAvailabilityJob.java#n51


 On 12 Jun 2015, at 19:57, Denis Roy denis@eclipse.org wrote:
 
 
 
 On 06/12/2015 01:15 AM, Marcel Bruch wrote:
 We are now looking forward to the first two weeks of the Mars release
 and cross fingers that we don’t get flooded.
 
 Marcel,
 
 Do we have an OFF switch somewhere so that we can turn these things off if 
 we see we're going to get flooded?
 
 Have we...?
 Do you...?
 
 
 I have a big OFF switch called a firewall, but I'm not sure how that will 
 manifest itself in Eclipse if the error reporter cannot connect to its home 
 site.
 
 Also, just so I understand, the 1000's of daily reports  (which could become 
 100,000's of daily reports on June 25) are all reports against the 
 recommenders server, right?  Not Bugzilla bugs, right? The latter could see 
 the OFF switch extended to your user account :)
 
 I will be at ECE to collect on any wrongdoings you do to your fellow 
 committers.
 
 In all seriousness, let me know if there's anything I can do to make sure 
 we're prepared for what is about to come.
 
 
 Denis
 ___
 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

[cross-project-issues-dev] Start collecting requests for Error Reporting v2

[Marcel Bruch]

Greetings ide-dev and cross-project-issues-dev,

Mars release is almost done. But 'after the release' is 'before the release’ 
and we already start making plans where to focus on for the error reporter’s 
next version. 

A small update on the numbers. Currently there are 43 individual and 23 project 
dev-mailing lists subscribed to receive daily or weekly error reports for their 
projects. In the last 9 months / since its inception we received ~170k error 
reports - with an rough average of 1000 error reports per day in the last 
months:




We are now looking forward to the first two weeks of the Mars release and cross 
fingers that we don’t get flooded. But after that period, we’ll reiterate the 
design and feature set and see how to improve the next version of the error 
reporter. I’d like to invite you to share your thoughts and requests - 
preferably via bugzilla [1], by email, or in person e.g. at EclipseCon France.

At EclipseCon France there will be a talk about the error reporter [2] in which 
I’ll sum up our experiences with automated error reports, common problems, 
acceptance and fixing rates etc. I’m looking forward to discuss future 
opportunities there as well.


Best,
Marcel

[1] http://eclip.se/4B http://eclip.se/4B
[2] http://eclip.se/4C http://eclip.se/4C

-- 
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

[cross-project-issues-dev] Proxy Testing Tool?

[Marcel Bruch]

Dear cross-projects,

for the error reporting we use the Apache HTTP Client to send error reports to 
its REST server. We spotted an issue how we handle proxies that require 
authentication - but were unfortunately not yet able completely fix it.

I wonder how other projects test proxied communication. Is there something like 
a “proxy simulator” or a set of test proxies you use? It would be great if 
others could share their setups.

In case s/o has deeper knowledge in using the Apache HTTP Client APIs: the code 
we use to configure our HTTP proxy is in [1].

All insights are welcome.

Thank you
Marcel


[1] 
https://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/tree/bundles/org.eclipse.epp.logging.aeri.ui/src/org/eclipse/epp/internal/logging/aeri/ui/utils/Proxies.java
 
https://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/tree/bundles/org.eclipse.epp.logging.aeri.ui/src/org/eclipse/epp/internal/logging/aeri/ui/utils/Proxies.java

——

Statistics for the latest RC:

Number of requests with no authentication:
P2: 3278
Apache: 3280

Number of requests with any (or unknown) authentication:
P2: 74
Apache: 30

Number of requests with NTLM authentication:
P2: 24
Apache: 6


___
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] automated error reporting

[Marcel Bruch]

Hi Greg,

daily digest contain errors that (i) have been reported in the past 24 hours 
and (ii) passed some thresholds like minimum number of users. For PTP the last 
report was on 2015-05-30 - which might explain why you did not get a daily 
digest in the last two days.

I assume you had a different expectation. Please let me know what you were 
expecting and we can work out how to accomplish what you are looking for.

Best,
Marcel


https://dev.eclipse.org/recommenders/committers/confess/#/problems/?projects=ptpkinds=NORMALpage=0size=10sort=modifiedOn,desc


 On 02 Jun 2015, at 15:14, Greg Watson g.wat...@computer.org wrote:
 
 Hi,
 
 I’ve enabled daily digests for PTP, but we’re not seeing any emails. Is there 
 something else I need to do? Does the error reporting address need to be 
 subscribed to the list?
 
 Thanks,
 Greg
 ___
 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] Project owning 'org.eclipse.event.recorder'

[Marcel Bruch]

FWIW, there is no package in simrel repo that contributes classes to this 
namespace. I agree that .qualifier sounds like a local test user. The class 
occurs in often along with classes of Papyrus. Maybe  some side project. I’d 
ignore this issue for now.

Best,
Marcel

 On 01 Jun 2015, at 21:31, Alexander Nyßen nys...@itemis.de wrote:
 
 I am not so sure about Google really saying so (at least I can’t find a hit 
 with the exact package name), but it seems to be a local bundle (the list of 
 active bundles lists it with 1.0.0.qualifier). Maybe its not related to an 
 Eclipse project at all, but the anonymous reporter has simply (mis-)used an 
 Eclipse namespace for some local bundle.
 
 Cheers
 Alexander
 
 Am 01.06.2015 um 20:48 schrieb Wim Jongman wim.jong...@gmail.com 
 mailto:wim.jong...@gmail.com:
 
 Google says TPTP ;)
 
 https://www.google.com/search?q=org.eclipse.event.recorder.listenersie=utf-8oe=utf-8
  
 https://www.google.com/search?q=org.eclipse.event.recorder.listenersie=utf-8oe=utf-8
 
 On Mon, Jun 1, 2015 at 7:25 PM, Alexander Nyßen nys...@itemis.de 
 mailto:nys...@itemis.de wrote:
 When triaging 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/55144304e4b0b71121dae2c4/details
  
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/55144304e4b0b71121dae2c4/details
  I ran across the package name ‚org.eclipse.event.recorder.listeners‘. Can 
 anybody tell which project owns it?
 
 Cheers
 Alexander
 --
 Dr. Alexander Nyßen
 Dipl.-Inform.
 Principal Engineer
 
 Telefon: +49 (0) 231 / 98 60-202 
 tel:%2B49%20%280%29%20231%20%2F%2098%2060-202
 Telefax: +49 (0) 231 / 98 60-211 
 tel:%2B49%20%280%29%20231%20%2F%2098%2060-211
 Mobil: +49 (0) 151 /  17396743 
 tel:%2B49%20%280%29%20151%20%2F%20%C2%A017396743
 
 http://www.itemis.de http://www.itemis.de/
 alexander.nys...@itemis.de mailto:alexander.nys...@itemis.de
 
 itemis AG
 Am Brambusch 15-24
 44536 Lünen
 
 Rechtlicher Hinweis:
 
 Amtsgericht Dortmund, HRB 20621
 
 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
 Trompeter, Sebastian Neus
 
 Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
 Fiorentino
 
 
 
 
 ___
 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
 
 ___
 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
 
 ___
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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 Reporting Tool Improvement

[Marcel Bruch]

Thanks for the feedback Ed. I understand your critique with the current blame 
logic. Unfortunately cutting off / ignoring frames below Display.runAsync or 
Display.runDeferred can have the opposite effect (missing the project that 
scheduled the ui runnable). I remember stacktraces that contained the necessary 
information below these frames. I’ll have to investigate further to find out 
how often we will be wrong with one or the other approach.

Carsten’s feature request is different from your request. While I’m (ATM) not 
convinced cutting off frames from a trace wont remove necessary information 
(some times), I can imaging to produce reasonable results by improving the 
blame function as you suggested. I created bug 466576 [1] to track your request 
specifically. I’ll post updates to this bug.

Thanks,
Marcel

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=466576 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=466576


 On 06 May 2015, at 14:00, Carsten Reckord reck...@yatta.de wrote:
 
 For cutting off the stack frames at Display.readAndDispatch() there's
 already https://bugs.eclipse.org/bugs/show_bug.cgi?id=451359.
 
 On 06.05.2015 13:54, Ed Merks wrote:
 Marcel,
 
 The error reporting tool is extremely cool and very useful!
 
 One aspect that could likely be improved significantly is the computation of 
 the 
 blamed projects.  In particular I'm having to triage many reports such as 
 this 
 one:
 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/54f9b544e4b0a38aecd742e2/details
 
 No doubt that's because Oomph is on the stack:
 
 
 
 I would like to suggest that the blame logic should consider that 
 Display.readAndDispatch processes events of arbitrary origin.  As such, 
 nothing 
 below that point in the stack is likely contributing to any problem above 
 that 
 point in the stack.
 
 Given that Oomph often starts a background dialog to perform tasks on 
 startup, 
 every possible problem that happens elsewhere in the IDE ends up in Oomph's 
 triage bucket,  so the list I must triage is large to the point where I'm 
 not 
 sure it can ever be managed:
 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/?projects=oomphkinds=NORMALkinds=FREEZEcategories=UNCONFIRMEDpage=1size=100sort=createdOn,desc
 
 The duplicates are a bit annoying too, but you have some nice support for 
 that 
 already:
 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/5522970ce4b026254ee014bf/similar
 
 Kudos for creating this great technology!
 
 Cheers,
 Ed
 
 
 
 
 
 
 
 
 ___
 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 Reporting Tool Improvement

[Marcel Bruch]

Hello cross-projects,

 On 06 May 2015, at 13:54, Ed Merks ed.me...@gmail.com wrote:


 I would like to suggest that the blame logic should consider that 
 Display.readAndDispatch processes events of arbitrary origin.

I spent some time analyzing how large the effect of such a change would be. I 
judged all differences between the current mappings and the new ones and have 
to say that in many cases this works better than the old approach. The results 
can be viewed live. Further suggestions are welcome. Please use bug 466576 [1] 
for that.


 Kudos for creating this great technology!

Maybe this is a good moment to ask committers on cross-projects to leverage the 
error reporting in their projects as well. Major projects like JDT, JSDT, 
Xtext, and EGit make good use of it and even large projects like JDT get around 
3-5 error reports per day to look at. In the last two weeks more than 70 
automated problem reports could been fixed and even external contributors start 
chasing bugs to help making Eclipse Mars great (e.g. [2]).

Please contact me if you want to set-up email digests or automated reports to 
bugzilla for your project. I’m happy to help setting it up.


Best,
Marcel


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=466576 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=466576
[2] https://twitter.com/darkjabberwock/status/595269222063833090 
https://twitter.com/darkjabberwock/status/595269222063833090



___
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] Biweekly UI Freeze Reports Summary

[Marcel Bruch]

://dev.eclipse.org/recommenders/committers/confess/#/problems/5534d75fe4b026254ee058c8/details
1   -
 4.UI freeze of 1,5s in XtendActivator.createInjector (67) 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/553571fae4b026254ee05b5b/details
1   -
 5.UI freeze of 7.7s in XtendActivator.createInjector (67) 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/5539238de4b026254ee06842/details
1   -
 
 Xtext:
 
 1.UI freeze of 4.2s in BaseDocumentProvider.setDocumentContent (288) 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/54c4f015bee810030da07a93/details
 6   450481 https://bugs.eclipse.org/bugs/show_bug.cgi?id=450481
 2.UI freeze of 2.4s in ConfigurationElement.createExecutableExtension 
 (262) 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/54c4f60abee810030da0c901/details
  4   -
 3.UI freeze of 4.2s in XtextDocument$XtextDocumentLocker.internalReadOnly 
 (490) 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/54f39452e4b0eb19d1a17190/details
  2   -
 4.UI freeze of 2.4s in XtextDocumentProvider.setDocumentContent (198) 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/54f6d492e4b03058b001f568/details
2   -
 5.UI freeze of 1,5s in ConfigurationElement.createExecutableExtension 
 (262) 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/54d38236e4b0d2e72753bc6f/details
  2   -
 6.UI freeze of 7,7s in 
 ConfigurationElementHandle.createExecutableExtension (55) 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/5523d372e4b026254ee01b97/details
 2   -
 7.UI freeze of 2,9s in JavaProjectResourceSetInitializer.initialize (50) 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/552d0cfae4b026254ee041f8/details
 2   -
 8.UI freeze of 1,3s in ConfigurationElement.createExecutableExtension 
 (262) 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/55311b8ee4b026254ee053aa/details
  2   -
 9.UI freeze of 3,0s in LocalFile.openInputStream (382) 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/5538a6aee4b026254ee0652a/details
   2   -
 10.   UI freeze of 1.9s in 
 AbstractGuiceAwareExecutableExtensionFactory.create (51) 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/552d9383e4b026254ee043f2/details
  1   -
  
 
 Thank you for your assistance.
 Your friendly error-reports-inbox.
 

-- 
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

[cross-project-issues-dev] Updating to Lucene 5.x (from 3.5) for Neon M1 / Mars SR1

[Marcel Bruch]

Greetings cross-projects,

Lucene 3.5 is used in many projects but it’s old. Many improvements have been 
made since then. In particular the performance and memory consumption improved.

Lucene 3.5 ships as part of the Platform but with Mars SR1 / Neon M1 I’d like 
to update our contributions (Error Reporting, Code Recommenders) to use Lucene 
5.1.x. I’m not sure whether all Eclipse projects using Lucene have proper 
version constraints. Thus, I’d like to make all projects aware of this plan.

I’ve create bug 465874 to track this and get your comments on this, in case you 
see issues or have further requests.


Thanks,
Marcel

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=465874 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=465874___
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] Updates from the Automated Error Reporting

[Marcel Bruch]

Thank you Szymon. Regarding abbreviating the exception names: can you open a 
feature request at [1] and post the link here?
We abbreviate exceptions for space reasons and in many cases it works well IMHO 
- or can be learned quickly (as NPE). 
But if a sufficient number of people support this we will reconsider this 
decision (as done before by switching to Mylyn notifications instead of using 
normal dialogs).

Thank you,
Marcel


[1] https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EPPcomponent=logging 
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EPPcomponent=logging

 On 24 Apr 2015, at 17:26, Szymon Ptaszkiewicz 
 szymon.ptaszkiew...@pl.ibm.com wrote:
 
 Hi Marcel,
 
 If I may, I'd like to propose one enhancement to the error reporting tool:
 avoid abbreviating exceptions. I have come across different bugs that said
 RE in SomeClass.someMethod but the RE term was not consistent. It was
 either RuntimeException or ResourceException. Abbreviations like NPE are
 well-known and don't complicate the thing, but abbreviations like SISPSIE,
 NCDFE, LLTE, BPCE, SDRME and a few others are not obvious (well, at least
 for me). Would it be possible to use the full name of the exception instead
 of its abbreviation?
 
 Other than that, I love it and look forward to more! :)
 
 Szymon

-- 
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] Bug 456909 - Implementing Early Startup IStartup causes org.eclipse.core.runtime.CoreException

[Marcel Bruch]

FWIW,

so far this issue was reported in two platform error reports by ~500 users each 
[1,2]. I added a comment to these problem reports which informs users that the 
early startup extensions they use, stopped working properly in Eclipse Mars and 
that they should inform their plugin providers about this to allow them taking 
care of this in their code.


At least there is an (indirect but focused) way informing 3rd party plugin 
providers about this breaking change before Eclipse Mars is released.


Marcel


[1] 
https://dev.eclipse.org/recommenders/committers/confess/#/problems/551194a2e4b0b71121dad676/details
[2] 
https://dev.eclipse.org/recommenders/committers/confess/#/problems/54c4f0a7bee810030da08462/details




 On 11 Apr 2015, at 18:30, Konstantin Komissarchik 
 konstantin.komissarc...@oracle.com wrote:
 
 I appreciate Lars’s response on the bug with a pointer to the change in 
 question along with the rationale.
  
 I do want to state that communication regarding this was lacking. Evidence:
  
 1.   WTP 3.7 M6 (Mars) milestone build is affected by this issue. 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=459620
 2.   A number of third party plugins are similarly affected.
  
 Plugin developers rely on Eclipse Platform maintaining rock-solid backwards 
 compatibility. As such, instances where compatibility will be broken, should 
 be announced at the highest volume possible and with much repetition. In this 
 case, the particular extension point usage pattern was apparently deprecated 
 in Eclipse 4.2 before being removed in 4.5. It would have been good to add a 
 deprecation warning to the error log starting in 4.2 in order to ensure that 
 the affected plugin maintainers notice that they need to take action while 
 there is still plenty of time to plan for this. The final removal should have 
 also been announced on cross-project.
  
 Thanks,
  
 - Konstantin
  
 From: Konstantin Komissarchik [mailto:konstantin.komissarc...@oracle.com] 
 Sent: Friday, April 10, 2015 2:58 PM
 To: 'Cross project issues'
 Subject: Bug 456909 - Implementing Early Startup IStartup causes 
 org.eclipse.core.runtime.CoreException
  
 Could someone from the platform team comment on this issue?
  
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=456909
  
 Plugins that have an IStartup extension and worked fine on 4.4 are causing 
 exceptions to be logged when used on 4.5 milestones. This appears to be an 
 API behavior regression. The bug was filed in January and the platform team 
 has yet to comment on it…
  
 - 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

-- 
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] Updates from the Automated Error Reporting

[Marcel Bruch]

 On 24 Apr 2015, at 23:31, Matthias Sohn matthias.s...@gmail.com wrote:
 
 EGit / JGit:
 
 1.   IOE in FS.readPipe (431)181 -
 
 this was fixed 2 weeks ago
 https://git.eclipse.org/r/#/c/44794/
 and I linked a couple of instances of this problem report to the 
 corresponding bug 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=463349
 but I won't continue manually linking another 181 instances of the same 
 problem
 it looks like duplicate detection has a problem …

FWIW, I checked whether the error reporter behaves incorrectly.

The bug is linked to a report of Egit 4.0. 
The problem report referenced above is based on Egit 3.7.
Line numbers of the top 3 EGit classes are different and thus are not 
classified as being identical.
There are, however, ways how marking a problem as duplicate of another issue 
could be simplified. I’ll see what I can do.


I linked the report [1] with the above referenced bug. It won’t show up in the 
next reports.
With that, all users that run into this issue now get the info to update to the 
latest Egit version.


Best,
Marcel


[1] 
https://dev.eclipse.org/recommenders/committers/confess/#/problems/54f07e08e4b0eb19d1a16a07/triage
___
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] Enable intelligent content assist by default

[Marcel Bruch]

Fred,

thanks for your response.

 So, from my experience, *if* code recommenders were to be enabled by default, 
 then it'd need to have :
 1 - Codetrails crowdsource extension installed by default

Glad you like it. Adding that data to recommenders would fine with me.

 2 - subword completion disabled

The results of Actrl+space  with JDT and Subwords are the same. I don’t see 
the relation to Subwords yet.

 3 - [1] fixed before the Mars release

The problem has been discussed in bug 435660 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=435660. JDT requests a patch 
which probably would not make it into Mars. But we can implement a workaround 
for Mars.


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] Joint NN page for the release train

[Marcel Bruch]

Greetings.

No complains yet. Good. However, there’s a difference between _thinking_ that 
something is a good(not bad) idea and actually _implementing_ it.  Thus, before 
we start asking for modifications in PMI or settings up other solutions, I’d 
like to know who would be interested to participate. 

I had a good experience using a google form to aggregate feedback about an 
idea. Thus I set up a form and kindly ask you for your feedback [1]. I’ll 
publish the results on this list in a few days. 

Thank You
Marcel

[1] http://goo.gl/forms/lL6mzusnqO http://goo.gl/forms/lL6mzusnqO



 On 02 Feb 2015, at 11:30, Ed Willink e...@willink.me.uk wrote:
 
 Hi
 
 I think the PMI has/can have a full list of all the NNs, so is it possible 
 for the PMI to create an NN index similar to the Help Documentation index so 
 that the Platform NN links to the overall NN index? Impact one line per 
 project in an index.
 
 If we want a 'three item' overview, perhaps the PMI could supervise a list of 
 overview NN's.
 
 Regards
 
 Ed Willink 
 
 On 02/02/2015 10:14, Lars Vogel wrote:
 Hi Marcel, 
 
 I think the correct solution would be to extend the purpose of the Platform 
 NN to include newsitems from the EPP side. 
 
 Best regards, Lars
 
 On Mon, Feb 2, 2015 at 11:11 AM, Marcel Bruch marcel.br...@codetrails.com 
 mailto:marcel.br...@codetrails.com wrote:
 Greetings cross-projects,
 
 I’d like to get your thoughts about a joint NN page for Mars Milestones.
 
 The platform maintains a NN page [1] for changes on the Platform/JDT/PDE. 
 All press releases, blogs and tweets about new milestones are pointing to 
 this page and as such it is the most prominent place to present new 
 features, what’s new and upcoming in Eclipse.
 
 However, IMHO there are much more noteworthy things to talk about. For 
 instance, the addition of the automated error reporting in all EPP packages 
 is such a noteworthy item but it cannot be published on that page because it 
 does not belong to the SDK. I guess many projects have interesting NN as 
 well. While larger projects with a community/ popular webpage will certainly 
 write a blog post about their new features. Smaller ones with no prominent 
 website or large community lack such a space. In addition, bloggers etc. 
 will certainly not browse all project blogs to find all NNs. 
 
 Thus I wonder whether we should have a joint NN page for the whole release 
 train where every participating project could put, say, up to 3 items per 
 Milestone release with a picture and a short paragraph (as the SDK already 
 does).
 
 What do others think?
 
 
 Marcel
 
 
 
 P.S.: FWIW, every EPP package download page *has* a NN link in the side 
 menu where EPP packages can add their NN links. However, it’s not used much 
 and likely is not very popular (at least I assume that b/c I noticed it the 
 very first time today).
 
 [1] https://www.eclipse.org/eclipse/news/4.5/M5/ 
 https://www.eclipse.org/eclipse/news/4.5/M5/
 
 
 ___
 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
 
 
 
 -- 
 Geschäftsführer
 
 vogella GmbH
 
 Haindaalwisch 17a, 22395 Hamburg
 Amtsgericht Hamburg: HRB 127058
 Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
 USt-IdNr.: DE284122352
 Fax (032) 221739404, Email: lars.vo...@vogella.com 
 mailto:lars.vo...@vogella.com, Web: http://www.vogella.com 
 http://www.vogella.com/
 
 
 ___
 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
 
 No virus found in this message.
 Checked by AVG - www.avg.com http://www.avg.com/
 Version: 2015.0.5646 / Virus Database: 4273/9043 - Release Date: 02/02/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

-- 
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

[cross-project-issues-dev] Joint NN page for the release train

[Marcel Bruch]

Greetings cross-projects,

I’d like to get your thoughts about a joint NN page for Mars Milestones.

The platform maintains a NN page [1] for changes on the Platform/JDT/PDE. All 
press releases, blogs and tweets about new milestones are pointing to this page 
and as such it is the most prominent place to present new features, what’s new 
and upcoming in Eclipse.

However, IMHO there are much more noteworthy things to talk about. For 
instance, the addition of the automated error reporting in all EPP packages is 
such a noteworthy item but it cannot be published on that page because it does 
not belong to the SDK. I guess many projects have interesting NN as well. 
While larger projects with a community/ popular webpage will certainly write a 
blog post about their new features. Smaller ones with no prominent website or 
large community lack such a space. In addition, bloggers etc. will certainly 
not browse all project blogs to find all NNs. 

Thus I wonder whether we should have a joint NN page for the whole release 
train where every participating project could put, say, up to 3 items per 
Milestone release with a picture and a short paragraph (as the SDK already 
does).

What do others think?


Marcel



P.S.: FWIW, every EPP package download page *has* a NN link in the side menu 
where EPP packages can add their NN links. However, it’s not used much and 
likely is not very popular (at least I assume that b/c I noticed it the very 
first time today).

[1] https://www.eclipse.org/eclipse/news/4.5/M5/ 
https://www.eclipse.org/eclipse/news/4.5/M5/

___
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] Hudson fails to access http://download.eclipse.org/eclipse/updates/4.4-M-builds

[Marcel Bruch]

Our HIPP builds got stuck on accessing the p2 update site from 
download.eclipse.org. I restarted our jobs two times with the same effect. 
Running the very same build from my pc, however, does not seem to suffer from 
an unavailability of download.eclipse.org http://download.eclipse.org/. Does 
anyone else see this issue as well? If someone knows a workaround, I’d be happy 
hear…

Marcel



[INFO] Computing target platform for MavenProject: 
org.eclipse.recommenders:org.eclipse.recommenders.apidocs:2.1.12-SNAPSHOT @ 
/jobs/genie.technology.recommenders/gerrit.master.luna/workspace/plugins/org.eclipse.recommenders.apidocs/pom.xml
[INFO] Adding repository 
http://download.eclipse.org/eclipse/updates/4.4-M-builds 
http://download.eclipse.org/eclipse/updates/4.4-M-builds
[WARNING] Failed to access p2 repository 
http://download.eclipse.org/eclipse/updates/4.4-M-builds 
http://download.eclipse.org/eclipse/updates/4.4-M-builds, use local cache. 
Unable to read repository at 
http://download.eclipse.org/eclipse/updates/4.4-M-builds/compositeContent.xml. 
http://download.eclipse.org/eclipse/updates/4.4-M-builds/compositeContent.xml.
[WARNING] Failed to access p2 repository 
http://download.eclipse.org/eclipse/updates/4.4-M-builds/categoriesLuna 
http://download.eclipse.org/eclipse/updates/4.4-M-builds/categoriesLuna, use 
local cache. Unable to read repository at 
http://download.eclipse.org/eclipse/updates/4.4-M-builds/categoriesLuna/content.xml.
 
http://download.eclipse.org/eclipse/updates/4.4-M-builds/categoriesLuna/content.xml.
[WARNING] Failed to access p2 repository 
http://download.eclipse.org/eclipse/updates/4.4-M-builds/M20140925-0400 
http://download.eclipse.org/eclipse/updates/4.4-M-builds/M20140925-0400, use 
local cache. Unable to read repository at 
http://download.eclipse.org/eclipse/updates/4.4-M-builds/M20140925-0400/content.xml.
 
http://download.eclipse.org/eclipse/updates/4.4-M-builds/M20140925-0400/content.xml.

___
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] Your friendly error reports bot is suspended

[Marcel Bruch]

Yes, efxclipse is currently not tracked and before sending you emails, we need 
you to state your interest.


Since efxclipse can be installed on top of any existing Eclipse installation 
and to get most out of it, I think we should consider to equip more EPP 
packages with the error reporter. 

So far it’s part of the committers and modeling *Mars Milestone Builds* package 
since M3. There are requests pending to add it to the Java [1] and Scout [2] 
package. But maybe we should consider adding it to all EPP packages by default 
- similar to the EPP Marketplace client?


Since the quality of the platform (and our extensions to it) is of critical 
importance to many of us, I think it's an important and necessary step to learn 
about any kind of problems our users experience.

In the meanwhile the error reporting client got a lean UI making it easy for 
clients to report issues. The server side also got it's own UI (decoupled from 
Bugzilla), provides means to help committers triaging problems, requesting 
further information etc.

Projects like JDT, Egit, Xtext, Sirius, ECP and others embrace the error 
reporter as new input source for finding errors in their code base. Projects 
like the Platform, PDE, CDT carefully start using it and even a fair share of 
UI freezes have been recognized and fixed [4].

Although challenging, we made recognizable progress in detecting similar 
reports and prevent committers from being flooded with duplicated error reports.

The EF offered the necessary technical support and infrastructure to set up 
that service for the Mars Release.


All these points make me believe that adding an automated error reporting 
client should be added to the Eclipse IDE as a whole - similar to the EPP 
Marketplace client.

Adding it now to M5 also has the advantages that the server gets a fair stress 
test before the release, we get the chance to spot many more issues, and last 
but not least committers will be able to make an informed decision by M7 
whether or not to integrate it into the Mars release.


When we started the initiative, 20 committers on this mailing list supported 
the development of this feature [3]. What’s your feeling after 2 milestone 
phases? I created bug 457180 to track your feedback and opinion about adding it 
to all EPP packages with Mars M5. Thanks for casting your voice.


Marcel



[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=457081
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=457082
[3] 
https://docs.google.com/a/codetrails.com/forms/d/1BLbeAtu-pvz26aXgfP2v4Sm3ysPjkUknkxEJsj909Lk/viewform
[4] 
http://blog.vogella.com/2015/01/09/eclipse-git-gets-faster-ui-freeze-reporting-activated-by-default-in-saneclipse/
[5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=457180




 On 10 Jan 2015, at 09:11, Tom Schindl tom.schi...@bestsolution.at wrote:
 
 Do I = e(fx)clipse have to opt-in explictly if i want to go with option 2?
 
 Tom

___
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] Your friendly error reports bot is suspended

[Marcel Bruch]

Hi Maximilian,

thanks for your reply. JDT also opted-in to receive notifications directly via 
Bugzilla. Lars expressed his interest for the Platform. Together with EMFStore 
and EMF Client Platform there are already four projects that would prefer 
bugzilla notifications over daily digest emails.

Thus, we’ll add means which will allow committers to register their projects 
and choose from different notification strategies (Bugzilla, Daily Digest, 
None). I estimate that a (limited) version will be available around the 20.01. 
Limited means that we’ll offer to send bugs to a manually specified, fixed 
Product:Component:Version coordinate first. In a later stage we’ll guess 
Component and Version based on the class path information available in a 
report. 

If any other project is interested in getting notifications, please let me know 
your constraints. 


Thanks,
Marcel






 On 09 Jan 2015, at 14:25, Maximilian Koegel maximil...@emfstore.org wrote:
 
 Hi Marcel,
 
 first of all: I really appreciate your work in this matter and believe
 this is a very important step towards being able to prioritize issues to
 better server our users. Thank you!
 I agree with your proposal that is implementing option 2 and allow
 by-project opt-in for option 3. I would be interested in using option 3
 for EMFStore and EMF Client Platform, of course, also as a test driver.
 
 Cheers,
 Maximilian

___
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] Your friendly error reports bot is suspended

[Marcel Bruch]

I see three valuable ways:

1. Only report issues into the separate system and let committers review these 
items from time to time manually.
2. Report issues into the separate system and send daily reports to committers 
or project lists that there are new incoming problems.
3. Report issues into the separate system AND directly into the project’s 
bugzilla product/component.

Options 1. and 2. are on my todo list for M5. Your option 3 seems viable to me 
as well. 
My proposal: Projects that wish to receive error reports directly in bugzilla, 
should say so (e.g. by a decision on the mailing list) and specify the bugzilla 
component to assign these reports with. I’ll add an UI for that.

What do you/others think?

Best,
Marcel

 On 09 Jan 2015, at 05:04, Lars Vogel lars.vo...@gmail.com wrote:
 
 Hi Marcel,
 
 thanks for the information.
 
 From the platform.ui side I'm not sure that we will be able to adapt yet 
 another system for looking at bug reports. IIRC the update of Bugzilla 
 worked fine for us, with the only issue that the duplicate bug dedection has 
 marking not the main bug and therefore created a long dependency chain. But I 
 think this has been fixed.
 
 Would it be possible to configure your intermediate system per comment to 
 continue to create automatic Bugzilla entries? If yes, every project could 
 vote to use your new system or continue to work only in Bugzilla. 
 
 Best regards, Lars
 
 2015-01-08 8:55 GMT+01:00 Marcel Bruch marcel.br...@codetrails.com 
 mailto:marcel.br...@codetrails.com:
 Hi Lars,
 
 no, there is no bug for this. But an interim system is live and receives 
 errors. 
 
 The UI also offers basic search capabilities now. See [1] for an overview and 
 [2] for an example of a concrete query. It also offers a set of predefined 
 per-project queries (see below for a comprehensive list).
 
 
 Plans are to have it operational by M5 (end of January). Until M5 the 
 proposed workflow is as follows:
 
 1. Committers can review the 'project problem listings' (given below) once 
 per day
 2. For every new problem that (you think) needs a closer look, move it to 
 Bugzilla. Convenient support for this will be added tomorrow.
 
 
 Some notes about the interim system:
 1. Even if possible, please do not make any changes in ui except creating 
 bugs from there; they might get lost during system updates.
 2. Bugzilla is the only stable reference you have. Thus, move errors to 
 Eclipse’ Bugzilla if you think they are bugs and start working on them there.
 3. Once a bug was created in bugzilla, don’t look back or try to keep the 
 error reporting system in-sync. Eventually we’ll do that automatically.
 4. Problem statistics and duplicate detection results may look suspicious at 
 times. It's more challenging than it may look on a first sight to detect 
 duplicates in large, moving code bases. 
 
 Having said this, I’m happy to receive feature requests and suggestions by 
 email (probably better off this list) or, preferably, via bugzilla.
 
 Best,
 Marcel
 
 
 Unconfirmed problems by project Quickstarter Queries
 
 Acceleo 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/search?projects=acceleokinds=NORMALkinds=FREEZEcategories=UNCONFIRMED
 Ant 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/search?projects=antkinds=NORMALkinds=FREEZEcategories=UNCONFIRMED
 C/C++ Development Tools 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/search?projects=cdtkinds=NORMALkinds=FREEZEcategories=UNCONFIRMED
 Code Recommenders 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/search?projects=reckinds=NORMALkinds=FREEZEcategories=UNCONFIRMED
 Eclipse Debug 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/search?projects=debugkinds=NORMALkinds=FREEZEcategories=UNCONFIRMED
 Eclipse Platform 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/search?projects=platformkinds=NORMALkinds=FREEZEcategories=UNCONFIRMED
 EGit / JGit 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/search?projects=egitkinds=NORMALkinds=FREEZEcategories=UNCONFIRMED
 EMF Client Platform 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/search?projects=ecpkinds=NORMALkinds=FREEZEcategories=UNCONFIRMED
 Epsilon 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/search?projects=epsilonkinds=NORMALkinds=FREEZEcategories=UNCONFIRMED
 Graphical Modeling Framework 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/search?projects=gmfkinds=NORMALkinds=FREEZEcategories=UNCONFIRMED
 Graphical Modeling Tools 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/search?projects=gmtkinds=NORMALkinds=FREEZEcategories=UNCONFIRMED
 Help 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/search?projects=helpkinds=NORMALkinds=FREEZEcategories=UNCONFIRMED
 Java Debug Interface 
 https://dev.eclipse.org/recommenders/committers

Re: [cross-project-issues-dev] Weird p2 install behavior: doesn't take mandatory attribute into account

[Marcel Bruch]

-201412102000/
 [2] http://download.eclipse.org/recommenders/updates/head/
 [3] http://download.eclipse.org/releases/mars
 [4]
 https://git.eclipse.org/c/m2e/m2e-core.git/commit/m2e-maven-runtime/org.eclipse.m2e.maven.runtime/pom.xml?id=7e198c6ae5cffbd6fc45e0cb3b54492123d7e2e4
 [5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=403243
 
 ___
 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

[cross-project-issues-dev] Observation: Frequent UI freezes when working with files

[Marcel Bruch]

Hi,

I just want to share an insight I got from reviewing several ui freezes. One 
common cause for UI freezes are operations that touch the filesystem. For 
instance, File.isFile, File.lastModified, or 
WinNTFileSystem.getBooleanAttributes seem to be very expensive. From what I 
read on the internet it seems that some of these methods (e.g. getAttributes) 
may even take up to several seconds to return on windows systems.


This has been discussed elsewhere in the internet [1] and seems to be a 
long-standing issue in Java.



With this mail I’d like to make you aware of this (in case you did not know 
this before) and would like to encourage you to actually not execute file 
operations in the ui thread. We may also consider doing some kind of caching 
but such a discussion would by far be over my knowledge, and thus, should be 
left to discuss with the platform team. 

For now, I think we would benefit very much if every project that accesses 
files/resources would review their code and think about refactoring some part 
of the FileSystem work (even if it’s only checking a file’s attributes) into 
background processes.

Best,
Marcel


[1] 
http://stackoverflow.com/questions/20546676/webstart-winntfilesystem-getbooleanattributes-performance


-- 
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] Updates on Automated Error Reporting: Started with Mars M2

[Marcel Bruch]

Am 24.10.2014 um 15:39 schrieb Lars Vogel lars.vo...@gmail.com:

 2014-10-24 6:47 GMT+02:00 Eike Stepper step...@esc-net.de:
 
 Two thoughts came up:
 
 1) ... What about a simple Yes/No dialog prior to all the more complicated 
 choices for those users who chose to opt in? Maybe together with a hint for 
 where in the preferences they can change their mind later.
 
 +1 also a simple checkbox labeled with Do not show this dialog again or 
 Automatically report without showing this dialog should IMHO be added to 
 the error reporting dialog.

The dialog can be simplified - although not as much as suggested. The user 
needs to be able to see which data may get send.

I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=448771 and will simplify 
it until M3.

Thanks for the feedback,
Marcel




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Updates on Automated Error Reporting: Started with Mars M2

[Marcel Bruch]

Thanks David.

 Don't be too quick to write all those off as user error“. 

True. Although useful, it's a different use case than I’m currently heading for 
(finding problematic locations in code).
If we’d add this it would require some person reviewing those items and/or 
needs code to be written especially for that purpose.

If you are interested in getting those error messages (say, by mail or send to 
some web url / cgi script under your control) - let me know.
I’d be glad to send those reports to you to build your specialized reports.

Best,
Marcel



Am 09.10.2014 um 20:23 schrieb David M Williams david_willi...@us.ibm.com:

 Sound quite promising Marcel, not to mention cool!  :) 
 
 One caution though, about one specific item you mentioned several times:  
 ... users entering a non-existing update site url ... 
 
 Don't be too quick to write all those off as user error. Believe it or not, 
 some project's repositories include incorrect or obsolete reference sites. 
 That's one reason we stopped copying them to the Sim. Release repo. (That, 
 and there was just too many, to be meaningful to users). 
 
 I do not think there is a way to detect which were entered by user, and which 
 were data provided by a project's repo. 
 
 Perhaps you are talking about obvious typo's or something. But, if not, you 
 might want to keep a list of non-existing sites you find in the reports, in 
 a common cross-project bug, or something? (In the past, when I open bugs on 
 invalid ones, projects were very slow to fix, if they fixed at all.) 
 
 Good luck, 
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Updates on Automated Error Reporting: Started with Mars M2

[Marcel Bruch]

Hi,


there is an updated documentation of the error reporting tool at [1]. It 
contains a summary of the UI, guidelines how to use / leverage the system, and 
how to help.


It also contains a set of sample bugzilla queries listing new yet unconfirmed 
bugs of the last 7 days „by project“. These queries use a yet manual tagging.
Thanks for your help reviewing items on that list.

Best,
Marcel

[1] http://goo.gl/5CjFmJ


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Updates on Automated Error Reporting: Started with Mars M2

[Marcel Bruch]

 
com.some.thing but you plugin is calls my.other we don’t put your bundle on the 
list of present bundles.
We use this list of bundles to guess which Bugzilla product we file new issues 
against and guess the version from the report.


5. Use Bugzilla whiteboard field and keyword needinfo“ in bug reports:

The error reporter reads the values stored in the keyword and whiteboard field 
and presents them to the (next) reporter. For example, if you get an error 
message like the well-known ‚Resource is out of sync‘, the automated error 
reporter would send this error to eclipse.org and in turn would present the 
user a message like „Tip: Eclipse can keep track of resource changes 
automatically. To enable this, go to preferences  General  Workspace and 
enable 'use native polling‘.

Done right, users that experience such a problem may get immediate feedback how 
to solve these issues for all times.

In case the error report is not providing enough details, you may specify the 
„needinfo“ keyword. In that case, the next reporter get’s notified that a 
committer requested additional information and points him to the bug report.

We may extend this approach in the near future depending on your feedback and 
if you actually make use of it. So, let us know what you think.



Some notes on our plans for M3:
First priority is improving duplicate detection. As of today we correctly 
classify 50% of the bugs with a false positive rate of 1%. For the remaining 
50% we could do better…

Second priority is improving the Eclipse client. If you have usability 
suggestions, please open a bug agains Recommenders.Incubator product, 
Stacktraces component.

Using bugzilla as „ui“ is not perfect and we need to replace it some time in 
the future. For the time being, however, we’ll stay with Bugzilla until either 
Webmasters cut us off from Bugzilla because of too much traffic or we have to 
time to build a front-end more suitable for analyzing automated error reports.


And sorry for broken (old) links.
Short before M2 we changed the URL scheme so that all resources are now well 
protected; potentially private data is accessible for committers only. This, 
however, required a new (breaking) naming scheme. All new bug reports use the 
new urls but we did not fix the old ones. Sorry for the inconvenience this may 
have caused.

The error reports dashboard is now available at: 
https://dev.eclipse.org/recommenders/committers/dashboard/



Finally,
in case you’d like to integrate the error reporting tool into your EPP package, 
please contact your package maintainer. We’d be more than happy to receive many 
more error reports.


Best,
Marcel




Example links to review project specific reports below. You may take these as 
examples to create your own queries - or contact me for custom solutions:

[m2e]   http://eclip.se/2P
[oomph] http://eclip.se/2S
[mpc]   http://eclip.se/2R
[jdt]   http://goo.gl/ROkLsS
[all open last 7d] http://goo.gl/uN03c7


-- 
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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Update on Error Log Reporting for Mars Milestones

[Marcel Bruch]

- I apologize for cross-posting to several lists - 


Hello Eclipse Committers and Enthusiasts,


In the last meeting the architecture-council requested little more details 
about the current state of the error log reporting for Mars Milestone Builds, 
which I present in this email. 

The error log reporting got approval by EMO and can go live soon. Legal aspects 
in code are addressed; some administrative tasks need to be done but will be 
fixed in the next days hopefully. All in all, we are making good progress. For 
a quick summary of previous state please visit the slides available at [1].



Server Side
===

The error log reporter's web front-end is accessible via 
http://dev.eclipse.org/recommenders/. Please note that it requires you to 
authenticate with your Bugzilla ID and password and is only accessible for 
Eclipse *committers*.

The web front-end features, among other things, an error log dashboard which 
provides some top-level information like 
* how many reports have been processed in the past days, 
* which plugins participated often in error reports, 
* lists common exception messages,
* etc. 
It also offers some basic data query functionality to build your own personal 
dashboard. Feel free to use this to build your personal dashboard for plugins 
you’d like to monitor but keep in mind that the dashboard is still subject to 
change without prior notice.

Besides the dashboard, the error log reporting now reports new errors directly 
to Bugzilla. What’s „new“ is decided based on a hash computed from all stack 
trace elements contained in an error report. From the way how the hash is 
computed you quickly get that this groups similar stack traces, i.e., stack 
traces that have exactly the same stack trace elements and order but ignores 
the error code, exact error message, and source code line numbers. This may or 
may not be a good decision. I initially planned to use error codes. But they 
are usually ‚0‘ (29%), ‚2‘ (42%), or ‚4‘ (25%) (see [4]) which effectively 
renders them quite useless. We’ll see what happens…

Anyways, as said, bugs are created for every new error that arrives. See 
http://eclip.se/2A for a list of example bug reports; see http://eclip.se/2B 
for a particular example. Please note that these bug reports may become visible 
for Eclipse committers only in the near future since these reports may contain 
sensitive information.

When looking at the description of http://eclip.se/2B more closely, you’ll 
notice that there are two links at the bottom. The first link sends you to the 
full error report that contains user names, unabbreviated messages, all child 
status objects with their stack traces etc. Thus, if the summary presented in 
the bug report may be missing something, please make sure to visit the details 
link.

The second link is an „update“ link which stores the current processing status 
(close, fixed, invalid, won’t fix etc.) in the error log reporter’s data base. 
This information is used to inform clients sending new reports about the 
current status of their issue. This feature is new and not yet really used on 
client side. But we have a couple of ideas how to make use of this in the 
future (e.g., the system could inform the user about reasons why this problem 
appears, committers may request for additional information from senders like a 
comprehensive installation log etc.) In case you have a good idea or feature 
request, let me know.

In addition to the stack trace, the bug report also contains a list of bundles 
(and their versions) that where present the exception's stack trace. Please 
note that this is a rather simple heuristic based on the package names present 
in the stack trace: For every package it checks whether there is an activated 
bundle with a similar name. If so, it’s added to the list. If the bundle is 
available in several versions, or we use split packages this may fail 
brilliantly. Thus, the list of present bundles may or may not be accurate. But 
it’s better than not guessing at all I guess…



Joining the review efforts
--

With reporting new errors to Bugzilla enabled, I’d like to encourage all 
committers to help reviewing error reports for their corresponding plugins. At 
the moment you have to define your own Bugzilla queries. http://eclip.se/2C 
gives and example how to register for error report containing 
„org.eclipse.m2e“. Please note that you can even specify arbitrary regular 
expressions for matching reports you are interested in. Bugzilla has a lot 
advanced query features to offer here.

In the near future we may be able to automatically add committers to a bug 
report’s cc list based on the bundles present in the stack trace, regex, or 
other metrics. This, however, would require some manual registration of the 
committer beforehand and is yet not available. At the moment I’ve to wait for a 
library to implement some missing features. I’ll give you a heads up as soon as 
such a 

Re: [cross-project-issues-dev] Update on Error Log Reporting for Mars Milestones

[Marcel Bruch]

Excuse me, I messed with the urls. Please use the ones below for the slides and 
dashboard:

https://docs.google.com/file/d/0B9Gf8BD0WA1SczNhZE43MnJ4Qzg/edit?pli=1
https://dev.eclipse.org/recommenders/dashboard/

Thanks,
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] [ide-dev] Update on Error Log Reporting for Mars Milestones

[Marcel Bruch]

Hi Sven,

the stacktraces are generally linked in bugzilla and are not available on the 
dashboard (at least not yet).

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=443906 which links to 
http://dev.eclipse.org/recommenders/reports/5412a8e7e4b07c26dfee01bd as 
detailed resource of the error report. That url returns a string representation 
of the comprehensive error report. Other, more fancy formats may be added over 
time if needed.

Marcel

Am 12.09.2014 um 10:15 schrieb Sven Efftinge s...@efftinge.de:

 Hi Marcel,
 
 the dashboard looks nice. Where can I see the full stack traces?
 
 Sven
 
 On 12 Sep 2014, at 10:04, Marcel Bruch marcel.br...@codetrails.com wrote:
 
 Excuse me, I messed with the urls. Please use the ones below for the slides 
 and dashboard:
 
 https://docs.google.com/file/d/0B9Gf8BD0WA1SczNhZE43MnJ4Qzg/edit?pli=1
 https://dev.eclipse.org/recommenders/dashboard/
 
 Thanks,
 Marcel
 
 ___
 ide-dev mailing list
 ide-...@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe from 
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/ide-dev
 
 ___
 ide-dev mailing list
 ide-...@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe from 
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/ide-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] Reporting interactive UI delays into the Error log

[Marcel Bruch]

Hi ,


Ed, 
I did not notice such an issue under mac. 
Preference page is under General » Tracing » Event Loop Monitor, at least on 
mac.

Lars,
the ui delays are reported as warnings not errors. Thus, the ui delay events 
won’t be picked up by the error log collector.
In addition, given that the amount of ui delays reported is quite large (at 
least on my machine and even at times where Eclipse has no focus).

If ui delays can detect deadlocks and reports them as errors they should be 
sent - but only if the user set the reporting mode to „send  always without 
asking“. Otherwise a dialog pops up asking for permission to send the event 
(which is - in the case of a UI deadlock… well...) So, I’m not sure that we’ll 
catch many of these events at the moment.

Marcel


Am 07.09.2014 um 11:27 schrieb Ed Willink e...@willink.me.uk:

 Hi Lars
 
 Really good initiative.
 
 But on a very new Windows 8.1 64 bit machine with minimal running 
 applications, even the Error Log view triggers the 0.5 second threshold. The 
 log fills at a rate of about 10 entries per minute. Many logged delays are in 
 the 5 to 10 second range, suggesting that my Eclipse should be glutinous, but 
 it feels fairly normal.
 
 Is this tool ready for use yet?
 
 The original Bugzilla has some discussion on a UI and preferences, but I 
 can't see any preferences. Am I blind (again)?
 
 Once a Bugzilla has been logged against some suspected offender, it would be 
 nice to be able to filter further logs from that offender.
 
 Regards
 
 Ed Willink
 
 On 02/09/2014 11:09, Lars Vogel wrote:
 Hi,
 
 Sometimes the Eclipse IDE freezes without providing feedback which part of 
 the code is responsible for the freeze. Such freezes should be avoided, but 
 it is often hard to determine the cause of the freeze.
 
 Platform.ui received a code contribution in 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=441015 to report such UI 
 delays into the Error View. In its default configuration it report delays   
 500 ms and adds a stack trace of the currently running code to the log 
 entry. 
 
 You can try this feature out from the following update site:  
 http://dl.bintray.com/vogellacompany/eclipse-performance-monitoring/  Works 
 in Luna and Mars.
 
 Platform.ui is planning to add this feature (deactivated by default) to the 
 Mars release. Feedback is welcome, if you find bugs in the tool, please 
 reported them 
 https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Platformcomponent=UI
 
 Best regards, Lars
 
 P.S. I have not yet tried it if the interactive error reporting from Marcel 
 but as UI delays are also reported to the Error log, Marcels plug-in should 
 also report it.
 
 
 
 ___
 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: 2014.0.4765 / Virus Database: 4015/8166 - Release Date: 09/06/14
 
 
 ___
 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] Reporting interactive UI delays into the Error log

[Marcel Bruch]

Lars,

will this feature be part of Mars M2?


Thanks
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] Automated Error Reporting for Mars Milestone Builds

[Marcel Bruch]

Hi Martin,

Am 31.08.2014 um 22:02 schrieb Oberhuber, Martin 
martin.oberhu...@windriver.com:

 Hi Marcel,
 
 I would be interested in using the tool internally at WindRiver.
 
 Could you share what is needed to set up an internal server for ourselves, 
 and how to replace the server IP in the code before we deploy it internally ?

Two changes are needed.
1. The server url is stored as preference. This needs to be adjusted. See 
/org.eclipse.recommenders.stacktraces.rcp/src/org/eclipse/recommenders/internal/stacktraces/rcp/PreferenceInitializer.java
2. The plugin id or at least one StackFrameElement has to start with 
org.eclipse (or com.codetrails. for testing at the moment). See 
org.eclipse.recommenders.internal.stacktraces.rcp.LogListener.startsWithRecommendersOrCodetrails(String)
 for details.

The server-side can be any script that takes the json and simply dumps it to a 
(nosql) database. That’s basically what it is right now.

 Also what tooling / methods you used to mine the logs …

There is neither a special tooling nor mining yet. The error analysis happens 
manually (as outlined in the slides). If there is a larger adoption of the 
system, I’d gonna take it to the next level and automated a few steps from what 
I’ve learned from the data received until then.


 I guess now that you've identified and filed 10-15 known bugs it would be 
 interesting if the tooling could already identify / classify the known bugs 
 at the client side (and no longer send duplicates).

There is a feature request pending that allows to specify ignore lists for 
errors. Said feature would allow to disable sending error reports completely or 
partially based on plugin-ids, error codes, messages, or stacktrace hashes. 
This is yet not implemented and had a slightly different intention, but get’s 
close to what you are looking for.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=442132 for details.

 As a user, I'd love to see an Advanced Errorlog in Eclipse that not only 
 shows me the original errors + stacktraces but also the tool's assessment 
 (known issue - bug_id, and severity).
 Known issues that have been identified as harmless could be shown green, 
 unknown issues red.

Interesting idea. Could you add a request to the Stacktraces Bugzilla for 
tracking? Here, however, I’ve to make my intension and goals clear. My goal is 
to spot and report issues in the milestone builds and study whether such a 
system can actually create added value for Eclipse. Although I like your idea, 
I likely won’t have the time to implement it. But if others would contribute 
such a feature, I’d be happy. 


 And ideally the tool would automatically download latest assessment data from 
 the server before uploading new data …

There is a request similar to yours in Bugzilla already. 
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=442719. 


 What do you think ?

Great input, great ideas. If you’d like to participate in the project or 
support it’s development in other ways, let me know...

Best,
Marcel


Am 31.08.2014 um 22:02 schrieb Oberhuber, Martin 
martin.oberhu...@windriver.com:

 Hi Marcel,
 
 I would be interested in using the tool internally at WindRiver.
 
 Could you share what is needed to set up an internal server for ourselves, 
 and how to replace the server IP in the code before we deploy it internally ?
 Also what tooling / methods you used to mine the logs ...
 
 I guess now that you've identified and filed 10-15 known bugs it would be 
 interesting if the tooling could already identify / classify the known bugs 
 at the client side (and no longer send duplicates).
 As a user, I'd love to see an Advanced Errorlog in Eclipse that not only 
 shows me the original errors + stacktraces but also the tool's assessment 
 (known issue - bug_id, and severity).
 Known issues that have been identified as harmless could be shown green, 
 unknown issues red.
 And ideally the tool would automatically download latest assessment data from 
 the server before uploading new data ...
 
 What do you think ?
 
 Thanks,
 Martin
 --
 Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
 direct +43.662.457915.85  fax +43.662.457915.6
 
 -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, August 30, 2014 11:21 AM
 To: Cross project issues; Recommenders developer discussions; Discussions 
 about the IDE
 Subject: Re: [cross-project-issues-dev] Automated Error Reporting for Mars 
 Milestone Builds
 
 Hi,
 
 we've just released an update of the automated error reporting tool [1] and 
 I'd like to share a few numbers and experiences I've made in the past 1 1/2 
 weeks.
 
 In the meanwhile we received ~1400 error events from ~30 users [4]. Many 
 events describe the same problem and of course most errors are not bugs. From 
 these 1400 events roughly half of them are caused by the same class

Re: [cross-project-issues-dev] Automated Error Reporting for Mars Milestone Builds

[Marcel Bruch]

Hi,

we’ve just released an update of the automated error reporting tool“ [1] and 
I’d like to share a few numbers and experiences I've made in the past 1 1/2 
weeks.

In the meanwhile we received ~1400 error events from ~30 users [4]. Many events 
describe the same problem and of course most errors are not bugs. From these 
1400 events roughly half of them are caused by the same class of issues. Based 
on the analysis of these error events, 10-15 bugs have been reported to various 
projects in and outside of Eclipse (PDE, Platform, JDT, Recommenders, EclEmma, 
Codetrails). Some of these have been fixed. Others didn’t peek interest of the 
project committers yet. The reasons may be manifold, but I haven’t heard back 
of them, and thus, can’t tell. 

If you have suggestions how to improve error reporting, please open a bug at 
[2] and let us know. See [5] for a list of bugs we’ve been working on and what 
else is currently the todo list – or at least in discussion. The source code is 
available at [7]. To get going quickly, I’d recommend to use Oomph as described 
in [3].

I’ve assembled a few slides describing the current state of affairs of the UI, 
which data is collected etc. See [6] for details.


If you have questions or if you have some input I/we should be interested in, 
please let me know.
Marcel


[1] http://download.eclipse.org/recommenders/updates/milestones/
[2] 
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Recommenders.Incubatorcomponent=Stacktracesversion=0.1.0
[3] http://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/about/
[4] 
http://recommenders.eclipse.org/dashboard/index.html#/dashboard/file/stacktraces.json
[5] http://eclip.se/2r
[6] 
https://docs.google.com/a/codetrails.com/file/d/0B9Gf8BD0WA1SczNhZE43MnJ4Qzg/
[7] 
http://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/tree/plugins/org.eclipse.recommenders.stacktraces.rcp



Am 19.08.2014 um 12:38 schrieb Marcel Bruch marcel.br...@codetrails.com:

 
 Anfang der weitergeleiteten Nachricht:
 
 Von: Marcel Bruch marcel.br...@codetrails.com
 Betreff: Aw: [cross-project-issues-dev] Automated Error Reporting for Mars 
 Milestone Builds
 Datum: 19. August 2014 12:34:39 MESZ
 An: Cross project issues cross-project-issues-dev@eclipse.org
 
 Hi,
 
 I noticed a few new users are sending errors. In response, I decoupled the 
 stacktraces  error reporting plugin from the Code Recommenders. Now you 
 should be able to install it without pulling in the complete Code 
 Recommenders stack.
 
 
 Some notes for testers:
 
  • I published the feature as „Code Recommenders Stacktraces  Error 
 Reporting Utility“  on Code Recommenders’ milestones update site [1].
  • Bugs and feature requests are collected and tracked in Bugzilla [2]. 
 Please make use of it for every request.
  • There are already a (small) amount of people contributing. Feel free 
 to contribute as well. Please read [3] on how to setup the project in 
 Eclipse with Oomph.
  • All stacktraces are sent *without any anonymization yet* (even if the 
 UI suggests that at the moment) to eclipse.org and can be publicly reviewed 
 at [4].
  • The plugin can be disabled temporarily by unselecting it in 
 Preferences » General » Startup and Shutdown (see Screenshot below) and 
 restarting your IDE
 
 
 
 Some general notes:
 
  • Feature updates happen frequently and without prior notice. Please 
 use the update manager to automatically look for newer versions from time to 
 time.
  • The code is yet not considered production-ready. It’s rather a 
 quick-’n-dirty prototype to gather community feedback. Not all features you 
 see today in the UI are already implemented (properly)
  • A releasable version is planned for Mars M2 timeframe and after we 
 got Legal approval by the EF.
  • The data in the dashboard [4] may be dropped due to schema changes. 
 We’ll keep this stable from Mars M2 but for now please consider the data 
 sent as experimental and temporary data.
 
 
 Thanks to all testers and feedback,
 Marcel
 
 
 [1] http://download.eclipse.org/recommenders/updates/milestones/
 [2] 
 https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Recommenders.Incubatorcomponent=Stacktracesversion=0.1.0
 [3] http://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/about/
 [4] 
 http://recommenders.eclipse.org/dashboard/index.html#/dashboard/file/stacktraces.json
 
 wizard01.pngwizard02.pngstacktraces-disable.png
 
 

___
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] Automated Error Reporting for Mars Milestone Builds

[Marcel Bruch]

Hi Lars,

Am 18.08.2014 um 11:13 schrieb Lars Vogel lars.vo...@gmail.com:

 Hi Marcel,
 
 I assume the project is based on the logger GSoC project. 
 
 Can you point to the documentation and source for this remote logger plug-in.

the eclipse error reporting prototype is hosted in recommenders main git 
repository at the moment. See [1] for instructions how to setup the project 
with Oomph. there is no additional documentation atm.


 Is it possible to use and configure it with an alternative backend server? 

Yes. the server url is stored as preference and may be changed by, e.g., 
plugin_customization.ini


Best,
Marcel


[1] http://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/about/






 Best regards, Lars
 
 
 2014-08-10 12:53 GMT+02:00 Marcel Bruch marcel.br...@codetrails.com:
 Hi cross-projects-issues,
 
 
 the Mars release train is picking up speed again and I’d like to propose 
 adding an error log reporting tool to the milestone builds that reports 
 errors to a central logging service at eclipse.org. 
 
 What’s cross-project’s take on this?
 Do you see a need and would you agree to add this to the milestone builds?
 
 
 
 The intension is obvious I think. Errors happen (especially during the 
 milestone builds). The sad thing is that it usually takes weeks until a user 
 recognizes them as such and reports them to Bugzilla – if ever. To help us to 
 get notified about issues in the current code base and fixing them as quickly 
 as possible, I’d like to add a log listener to the platform log which 
 automatically sends error log entries to a server at eclipse.org.
 
 The proposed user-workflow is pretty simple:
 Whenever an error is logged to the Eclipse error log, that service checks 
 whether it’s an error logged by an Eclipse plugin (by checking the plugin id 
 starts with „org.eclipse“). If so, it opens a dialog asking the user for 
 permission to send that error to our server (recommenders.eclipse.org) for 
 further processing. For a brief summary of the UI, please see the wizard 
 screenshot below.
 
 
 On the server side, the error is logged and we (ATM me) are notified by email 
 that there is something new to analyze. There is also a dashboard [1] that 
 allows committers to review which errors have been logged in the past, say, 7 
 days and to analyze the submitted errors. If of interest, that system can be 
 extended to send errors by email to selected committers based on some search 
 criteria like containing „org.eclipse.your-project“ in a stacktrace etc.
 
 For details about the submitted data, please study one of the example error 
 log entries in [1]. It contains all data that would be sent.
 
 
 
 To pick up the question from the beginning: What’s cross-project’s take on 
 this? Should such a feature be added to the milestone builds? 
 I sure that EF needs to give their permission, but the general question is 
 whether we’d like to know (and get notified in such a way) about errors our 
 users experience. From my experience only few people discuss on 
 cross-projects. But maybe you can cast your voice in a mini-survey [2]?
 
 
 Marcel
 
 
 [1] 
 http://recommenders.eclipse.org/dashboard/index.html#/dashboard/file/stacktraces.json
 [2] 
 https://docs.google.com/forms/d/1BLbeAtu-pvz26aXgfP2v4Sm3ysPjkUknkxEJsj909Lk/viewform
 
 
 
 error-reporting-wizard.pngBildschirmfoto 2014-08-10 um 12.24.13.png
 
 
 ___
 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

___
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] Automated Error Reporting for Mars Milestone Builds

[Marcel Bruch]

Thanks Ivan. I added the obfuscate option to the list of potential improvements.



Am 11.08.2014 um 10:05 schrieb Ivan Inozemtsev ivan.inozemt...@xored.com:

 +1, I'd love to have this feature not only for milestone builds. Several 
 years ago at Xored we were trying to build a similar system for server-side 
 error log collection and grouping, with additional collection of extra 
 information like jre version, os name, memory settings, disk usage, but 
 couldn't find enough resources to make it live.
 
 Additional note – sometimes, even during email communication, people don't 
 send error logs because they don't want to reveal their proprietary bundle 
 IDs (so they don't want you to know their company/product name), or send logs 
 with those ids are replaced by asterisks. So maybe having an option like 
 obfuscate non-eclipse bundles and class names could potentially attract 
 such users.
 
 Ivan Inozemtsev

___
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] Automated Error Reporting for Mars Milestone Builds

[Marcel Bruch]

Just a brief summary of the current poll results [1]

+1: 7 people voted for adding this feature.
±0: 0 people had no opinion
-1:  0 people voted for not adding this feature

Not too many, but it’s summer… 
If anyone still likes to cast his/her voice, please visit [2].



Wayne, Mike,
I assume adding such a feature to any EPP package needs permission of the EMO.
What would be required from your side? Do you need any number of votes for or 
against that proposal?


Marcel

[1] 
https://docs.google.com/spreadsheets/d/16JOCI1Z_cQK89eCMbPBxLp-r8kuj_oFAULCvyUZ8FIQ/edit?usp=sharing
[2] 
https://docs.google.com/forms/d/1BLbeAtu-pvz26aXgfP2v4Sm3ysPjkUknkxEJsj909Lk/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] Luna RC3 repository is available

[Marcel Bruch]

Might well be that this is due to a restructuring we did on our third-party 
dependencies. We had potential conflicts with Xtext and Guice. We removed the 
Guice inclusion in one of our features and rely on p2 that it pulls in the 
required Guice bundles. Since there is no separate source feature that 
contributes Guice sources now, this might explain why it’s not there anymore.

I’m OK with it (obviously). If someone else needs it, we should rethink how we 
distribute sources for Guice. I’m generally not aware of any good solution how 
to distribute source bundles for 3rd party bundles in the platform. If there is 
a common way, please let me know.

Marcel


Am 07.06.2014 um 09:24 schrieb Tom Schindl tom.schi...@bestsolution.at:

 Hi,
 
 It looks like the RC3 repo is missing com.google.inject.source. I know
 that i can not generally assume source-bundles are there but it has been
 there since always but started missing today.
 
 I have no problem fetching it from the orbit repo if you think it is OK
 that it is missing.
 
 Tom
 
 On 06.06.14 16:03, David M Williams wrote:
 I've made the RC3 repository visible under the build-in repository at
 
 http://download.eclipse.org/releases/luna/
 
 The EPP packages will be available soon, if not already, from
 
 http://www.eclipse.org/downloads/index-developer.php
 
 Happy testing!
 
 
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [ide-dev] EclipseCon Meeting to discuss LDAP-based preference management

[Marcel Bruch]

Hi ide-dev,
(cc'ed cross-project)


I summarized the EclipseCon meeting about preference management for Eclipse. We 
additionally discussed briefly an error reporting tool. Please look at the 
notes here [1]. Pascal, I think you can add valuable news to the error 
reporting section since you are doing something similar at Ericsson (if I 
remember correctly)?

Feel free to send comments to the list or add them directly to the document.

Best,
Marcel

[1] 
https://docs.google.com/document/d/1fEbVfCxJ7ds8ZXNM1uCL5wiqBb46FE-2Xss1cyIVrPw/edit?usp=sharing

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] m2e ponders participation in luna

[Marcel Bruch]

FWIW,

we have a dependency to m2e runtime. 
With m2e’s move to 1.5 and switching from Sonatype Aether to Eclipse Aether 
Incubation we have a similar issue.

We can fall back to the 1.4 maven runtime, though. 
A release of Eclipse Aether (this component contains 98% of what we need) would 
help - but I’ve no insight into Eclipse Aether release plans [1].


[1] 
http://www.eclipse.org/projects/project-plan.php?planurl=/aether/plan/current.xml


Am 16.12.2013 um 05:06 schrieb Igor Fedorenko i...@ifedorenko.com:

 Hello,
 
 I just pushed updated version of m2e 1.5 plan.xml to our git
 repository [1]. I will let technology pmc and other eclipse powers
 decide if this is good enough for m2e to stay in simultaneous release.
 
 Also, in line with our use latest released maven recurring theme, we
 updated m2e to include maven 3.1.1 earlier this year and there is a
 50/50 chance will update to maven 3.1.2, provided it is released before
 luna ip deadline. Problem is, maven 3.1.x includes Eclipse Aether and
 Eclipse Sisu binaries, both currently under incubation as eclipse
 technology project.
 
 My questions are
 
 Can m2e get an exception to ship incubating components in a mature
 project on the grounds that m2e includes released maven version, which
 just happens to include eclipse incubating project binaries?
 
 If m2e has to go back to incubation, will java and java ee epp
 package maintainers be willing to keep m2e in?
 
 [1] 
 http://git.eclipse.org/c/www.eclipse.org/m2e.git/commit/?id=6c18b3cf58143f5f462f2f3b601ef2996887ef07
 
 --
 Regards,
 Igor
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [technology-pmc] Fwd: [eclipse.org-planning-council] Luna participation

[Marcel Bruch]

 To join a Simultaneous Release, Projects must have stated their intent to do 
 so by M4, at the latest. The statement of intent is done by formally 
 announcing participation on the cross-projects-issues-dev mailing list (EMO 
 will update the Luna participation page). Projects are expected to have a 
 release record completed that includes (at least tentative) plan information 
 prior to announcing their intent to participate. The announcement must 
 include the name of the project, a link to the release record, and the offset 
 (+0, +1, …)


Code Recommenders will join the release with a 2.x  version.
The project plan for 2.0 is available here [1]. 
Our offset is +3 as we depend on a couple of projects (xtext, xtend, jgit, m2e) 
and have no known dependents.

Thanks,
Marcel

[1] 
http://projects.eclipse.org/projects/technology.recommenders/releases/2.0.0/plan


On Sep 9, 2013, at 4:53 PM, Gunnar Wagenknecht gun...@wagenknecht.org wrote:

 FYI: If you are a Technology project and plan to participate in Luna please 
 make sure to read through the following email as well as subscribe to the 
 cross-project-issues-dev@eclipse.org mailing list (if not already done so).
 
 Thanks!
 
 -Gunnar
 
 Anfang der weitergeleiteten Nachricht:
 
 Dani 
 
 
 From:Wayne Beaton wa...@eclipse.org 
 To:eclipse.org-planning-coun...@eclipse.org 
 Date:29.08.2013 05:03 
 Subject:[eclipse.org-planning-council] Luna participation 
 Sent by:eclipse.org-planning-council-boun...@eclipse.org 
 
 
 
 Greetings Planning Council.
 
 With Kepler, I populated the participating projects page [1] in the PMI 
 based on the contents of the portal. As projects showed up late, I updated 
 the page manually.
 
 I've created a page for Luna [2] and have updated the process in the 
 documentation [3].
 
 The short version is that I've turned things around with the new 
 implementation. In the old implementation, a project had to flip the bit 
 in their own project metadata via the portal. This was pretty difficult to 
 track as there was no notification when a change occurred, and there was no 
 restriction on when the bit could be flipped. Several projects added 
 themselves retroactively to one or more releases.
 
 The current implementation starts from the Simultaneous Release record. To 
 that record, I can add a project, version, and offset. My intention is open 
 this functionality up to Planning Council members, but I haven't got that 
 implemented yet. In the meantime, it has to be me that makes the change.
 
 I will monitor the cross-project-issues-dev mailing list and update the 
 record as declarations of participation come in. I'll look to the top-level 
 project representatives on the Planning Council to make sure that no 
 projects are forgotten (i.e. tell me if you notice a discrepancy). Making 
 projects use the mailing list has the benefit of ensuring that they're 
 actually on the mailing list. It has the further advantage of giving me an 
 opportunity to press projects to create a release record and populate it 
 with plan information. Again, I look to the top-level project 
 representatives to assist with this.
 
 There is likely going to be some confusion, especially for projects that 
 have been participating for a while. I will make an announcement on the 
 cross-project-issues-dev mailing list describing the change in process.
 
 Wayne
 
 [1] https://projects.eclipse.org/releases/kepler
 [2] https://projects.eclipse.org/releases/luna
 [3] 
 http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#State_intent_early_.28M4.29
  
 -- 
 Wayne Beaton
 Director of Open Source Projects, The Eclipse Foundation
 Learn about Eclipse Projects
 [attachment attm1uit.htm deleted by Daniel Megert/Zurich/IBM] 
 ___
 eclipse.org-planning-council mailing list
 eclipse.org-planning-coun...@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
 
 IMPORTANT: Membership in this list is generated by processes internal to the 
 Eclipse Foundation.  To be permanently removed from this list, you must 
 contact e...@eclipse.org to request removal. 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 
 -- 
 Gunnar Wagenknecht
 gun...@wagenknecht.org
 
 
 
 
 
 ___
 technology-pmc mailing list
 technology-...@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/technology-pmc

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev