Re: [cross-project-issues-dev] The end of an era: shell access.

[Doug Schaefer]

FWIW, I used my shell access to poke around the downloads area to find things 
in our massive collection of p2 repositories in the download area. sftp worked 
just fine for that. Except maybe for the manual 'find' you end up doing to find 
things in directory trees.

Cheers,
Doug.


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Greg Watson 
[g.wat...@computer.org]
Sent: Monday, July 29, 2019 9:07 AM
To: Cross project issues
Cc: eclipse.org-committ...@eclipse.org
Subject: Re: [cross-project-issues-dev] The end of an era: shell access.

I would like to thank Jonah Graham for helping us to overcome this restriction 
imposed on us by the Foundation. Thanks Jonah!

Greg

On Jul 5, 2019, at 9:43 AM, Greg Watson 
mailto:g.wat...@computer.org>> wrote:

I will also add that I’ve had shell access to 
build.eclipse.org
 for release engineering for something like 15 years, so this would affect me 
to the extent that I would be dropping support for the PTP project. If the 
foundation wants to do this then it should be providing a generic automated 
release process that all projects use, and in the interim provide the resources 
to convert manual release processes to CI-driven ones. If they do this, then I 
might reconsider, but it would depend on how difficult things become.

Regards,
Greg

On Jul 4, 2019, at 3:49 PM, Eclipse Webmaster 
mailto:webmas...@eclipse-foundation.org>> 
wrote:

Hi Everyone,

  As some of you may know we have traditionally provided a limited set of 
committers with shell access to 
build.eclipse.org,
 and all other committers having restricted shells.

For the last couple of years[1][2] we've been working to reduce that number as 
far as possible, and the time has come to finish the process.

Effective August 28th 2019 we will be transitioning all committers that still 
have a regular shell to our restricted shell.  You will still be able to use 
SFTP and SCP to interact with the downloads and archive areas(but we suggest a 
job on your Eclipse CI instance!)

If you have any questions or concerns please feel free to contact Webmaster.

-Matt.

[1] 
https://www.eclipse.org/lists/cross-project-issues-dev/msg06625.html
[2] 
https://www.eclipse.org/lists/eclipse.org-committers/msg01075.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://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 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] SimRel 2019-06 Release Candidate 2 (RC2) staging repo is complete

[Doug Schaefer]

If that's the rule, it should really be captured here:

https://wiki.eclipse.org/SimRel/2019-06/Simultaneous_Release_Plan

Also interesting that the GA date keeps getting earlier. We're in mid-June 
territory now...

Doug.


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Frederic Gurr 
[frederic.g...@eclipse-foundation.org]
Sent: Thursday, June 13, 2019 12:04 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] SimRel 2019-06 Release Candidate 2 
(RC2) staging repo is complete

Hi,

The quiet period officially starts tomorrow, but the EPP build is always
on a Thursday. Unfortunately, last minute contributions have started to
bleed into Thursday for a while now, even though they should be done by
Wednesday EOB.

Are you okay with leaving out that change?

Regards,

Fred

On 13.06.19 17:58, Greg Watson wrote:
> No, not critical, but I thought tomorrow was the start of the RC2 quiet 
> period?
>
> Greg
>
>> On Jun 13, 2019, at 11:45 AM, Frederic Gurr 
>>  wrote:
>>
>> Hi,
>>
>> Is this a critical fix?
>>
>> Regards,
>>
>> Fred
>>
>> On 13.06.19 16:24, Greg Watson wrote:
>>> I have an update that only went into the build today because a previous 
>>> Gerrit changeset was never validated. Is it possible to run the aggregation 
>>> again today? Sorry for the last minute issue.
>>>
>>> Thanks,
>>> Greg
>>>
 On Jun 13, 2019, at 9:43 AM, Frederic Gurr 
  wrote:

 Hi,

 Since the SimRel aggregator build is quiet, I declare the staging repo
 for 2019-06 RC2 to be complete.

 As usual, it can be found here:

 => 
 https://urldefense.proofpoint.com/v2/url?u=http-3A__download.eclipse.org_staging_2019-2D06_=DwICAg=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc=Kxo5hO9B2vR-RsF79RhPB4XXe9-ohDFoJvX3O40qggU=yyVFt7Kg-duKjZ89Yo9TCo-e3CcfHTVh4J9mMbNFX0M=

 Please note, we will enter quiet days for 2019-06. If no blocking
 issues are found, RC2 will become the official 2019-06 release on
 Wednesday, June 19th.

 Thanks for all your contributions and happy _quiet_ days!

 Regards,

 Fred


>>
>> --
>> Frederic Gurr
>> Release Engineer | Eclipse Foundation Europe GmbH
>>
>> Annastr. 46, D-64673 Zwingenberg
>> Handelsregister: Darmstadt HRB 92821
>> Managing Directors: Ralph Mueller, Mike Milinkovich, Chris Laroque
>> ___
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev=DwICAg=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc=Kxo5hO9B2vR-RsF79RhPB4XXe9-ohDFoJvX3O40qggU=Ys6M874QOeeDzWafEyaZs0kC6STit_ELSN-vnRBUS1g=
>
> ___
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev=DwICAg=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc=Kxo5hO9B2vR-RsF79RhPB4XXe9-ohDFoJvX3O40qggU=Ys6M874QOeeDzWafEyaZs0kC6STit_ELSN-vnRBUS1g=
>

--
Frederic Gurr
Release Engineer | Eclipse Foundation Europe GmbH

Annastr. 46, D-64673 Zwingenberg
Handelsregister: Darmstadt HRB 92821
Managing Directors: Ralph Mueller, Mike Milinkovich, Chris Laroque
___
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://urldefense.proofpoint.com/v2/url?u=https-3A__www.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev=DwICAg=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc=Kxo5hO9B2vR-RsF79RhPB4XXe9-ohDFoJvX3O40qggU=Ys6M874QOeeDzWafEyaZs0kC6STit_ELSN-vnRBUS1g=
___
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] Java 11 recommendations

[Doug Schaefer]

I've been considering AdoptOpenJDK, especially now that they have builds for 
all three major platform. Is that a road well travelled?

https://adoptopenjdk.net/releases.html

Doug.

On Tue, 2018-12-11 at 21:38 +0100, Mikaël Barbero wrote:
Ed,

See https://wiki.eclipse.org/Jenkins#JDK to see what versions we provide in 
build environments. There is also a note about new Oracle JDK licensing.

HTH.

Mikaël Barbero
Team Lead - Release Engineering | Eclipse Foundation
 (+33) 642 028 039 |  @mikbarbero
Eclipse Foundation: The Platform for Open Innovation 
and Collaboration

Le 11 déc. 2018 à 21:16, Mike Milinkovich 
mailto:mike.milinkov...@eclipse-foundation.org>>
 a écrit :


There is no policy on the Java version. But I don’t understand why anyone would 
elect to use Java under the OTN license when you could also use it under the 
GPL+CE?

Mike Milinkovich
mike.milinkov...@eclipse-foundation.org
(m) +1.613.220.3223

On Dec 11, 2018, at 12:10 PM, Ed Willink 
mailto:e...@willink.me.uk>> wrote:

Hi

Is there an EF policy on what Java 11 should be used?

https://www.computerweekly.com/opinion/Beware-of-Oracles-developer-Trojan

suggests that the Oracle JDK that I have used in the past may no longer be 
appropriate.

Please advise.

Regards

Ed Willink



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
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 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] Eclipse.org timeouts for bugzilla, gerrit, git

[Doug Schaefer]

I’m having trouble accessing download.eclipse.org. And I can throw a rock and 
hit the servers from here. Maybe I should .

Doug.

From: cross-project-issues-dev-boun...@eclipse.org 
 On Behalf Of Daniel Megert
Sent: Friday, October 12, 2018 9:55 AM
To: Cross project issues 
Subject: Re: [cross-project-issues-dev] Eclipse.org timeouts for bugzilla, 
gerrit, git

Works fine for me.

Dani



From:"Mikaël Barbero" 
mailto:mikael.barb...@eclipse-foundation.org>>
To:Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Date:12.10.2018 15:50
Subject:Re: [cross-project-issues-dev] Eclipse.org timeouts for 
bugzilla, gerrit, git
Sent by:
cross-project-issues-dev-boun...@eclipse.org




Do you still face the issue?

We had an issue with connection limits, but Denis increased them and it now 
works for me.

Cheers,

Mikaël Barbero
Team Lead - Release Engineering |Eclipse Foundation
 (+33) 642 028 039 |  @mikbarbero
Eclipse Foundation: The Platform for Open Innovation 
and Collaboration

Le 12 oct. 2018 à 13:56, Mikaël Barbero 
mailto:mikael.barb...@eclipse-foundation.org>>
 a écrit :

I'm experiencing the same issue currently. However, I see no evidence that the 
issue is on the infra side.

Will keep you posted.

Thanks.

Mikaël Barbero
Team Lead - Release Engineering |Eclipse Foundation
 (+33) 642 028 039 |  @mikbarbero
Eclipse Foundation: The Platform for Open Innovation 
and Collaboration

Le 12 oct. 2018 à 13:27, Andrey Loskutov 
mailto:losku...@gmx.de>> a écrit :

Hi,

Looks like eclipse.orgis hardly accessible: I get 
extremely large response times or timeouts for bugzilla, gerrit, git.

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

[attachment "signature.asc" deleted by Daniel Megert/Zurich/IBM] 
___
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] Simultaneous Release Opt-in announcements

[Doug Schaefer]

CDT is participating, of course. We don’t know what release yet. At this point 
it’s very likely a maintenance release off the 9.5 branch. But as we are 
pushing those out on demand, we won’t know which one until the rampdown starts 
when we’ll lock it in.

But, yes, at the very least can we create another mailing list for these. It’s 
created a lot of noise in my inbox and we have other very important topics to 
look out for.

Doug.

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Wayne Beaton
Sent: Monday, July 16, 2018 10:38 AM
To: Cross project issues 
Subject: [cross-project-issues-dev] Simultaneous Release Opt-in announcements

These "kind of annoying" announcement messages serve a couple of purposes.

They ensure that project teams are actually engaged on the primary 
communication channel for the simultaneous release. This comes in handy, for 
example, when project teams change composition (e.g. key players move on), 
knowledge gets lost, or project teams otherwise end up disengaged. When we 
notice that projects are missing at the opt-in deadline, it's way easier to 
mitigate than when we notice it at the end of the release cycle. FWIW, we have 
to chase down at least a couple of projects every year.

The requirement to make an explicit communication basically forces project 
teams to create a release record and start their planning and communication 
regarding the release. Of course, this presupposes that creating a release 
record at the beginning of a release cycle is valuable.

The Eclipse Development Process states, in part:

Projects are required to make a project plan available to their community at 
the beginning of the development cycle for each major and minor release. The 
plan may be as simple as a short description and a list of issues, or more 
detailed and complex.

The Architecture Council is in the process of updating the Eclipse Development 
Process. If anybody would like to consider changing any of these, I recommend 
that you take that up with your PMC representative on the council.

With the evolution of the simultaneous release to a rolling release process, I 
half expected that the Planning Council might decide to require explicit opt-in 
on a quarterly basis. I'm delighted that they've instead decided to not raise 
the burden and instead just require a single annual check in.

I am thinking, though, that with the increase in frequency of releases, it's 
time to rethink how we track participation in the release. We may consider 
investing some energy in deriving this information from the aggrcon files. 
This, of course, assumes that tracking this information is actually valuable 
(and ignores that we have some projects that participate in the simultaneous 
release, but do not contribute bits to the aggregate repository). The explicit 
tracking has proven helpful for marketing purposes, and helps those of us who 
work at a higher level than an individual project.

I don't know how to achieve all of this in an easier manner than a 
once-per-year email. If you have suggestions for alternatives, please connect 
with your PMC's Planning Council representative to have them bring this 
discussion to the PC.

Thanks,

Wayne
--
Wayne Beaton
Director of Open Source Projects
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

Re: [cross-project-issues-dev] [tools-pmc] [epp-dev] Photon RC4 EPP packages

[Doug Schaefer]

Well, given this is the only reaction we’ve received from the Planning Council, 
and we’ve heard no objections, let’s consider it unanimous ☺.

Now, who has the power to push the build button and get the bits in place?

Doug.

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Nick Boldt
Sent: Monday, June 18, 2018 11:56 AM
To: Tools PMC mailing list 
Cc: Cross project issues ; Eclipse 
Packaging Project 
Subject: Re: [cross-project-issues-dev] [tools-pmc] [epp-dev] Photon RC4 EPP 
packages

I'm on the Planning Council. +1 for respin (if you also include my fix for the 
JavaEE EPP bundle [1]). :)

[1] https://git.eclipse.org/r/#/c/124633/

Cheers,

Nick



On Mon, Jun 18, 2018 at 11:46 AM, Doug Schaefer 
mailto:dschae...@blackberry.com>> wrote:
I’m on the PMC. Again, Alex, our rep, and the rest of the planning council 
should know about this by now.

BTW, every minute we wait, assuming the request is approved, pushes everything 
back.

Doug.

From: epp-dev-boun...@eclipse.org<mailto:epp-dev-boun...@eclipse.org> 
[mailto:epp-dev-boun...@eclipse.org<mailto:epp-dev-boun...@eclipse.org>] On 
Behalf Of Daniel Megert
Sent: Monday, June 18, 2018 11:39 AM

To: Eclipse Packaging Project mailto:epp-...@eclipse.org>>
Subject: Re: [epp-dev] Photon RC4 EPP packages

It's not about "watching". You have to go to your PMC and the PMC to the 
Planning Council.

Dani



From:Doug Schaefer 
mailto:dschae...@blackberry.com>>
To:Eclipse Packaging Project 
mailto:epp-...@eclipse.org>>
Date:18.06.2018 17:33
Subject:Re: [epp-dev] Photon RC4 EPP packages
Sent by:epp-dev-boun...@eclipse.org<mailto:epp-dev-boun...@eclipse.org>



Not sure, I’m assuming the planning council including Alex is watching the 
cross projects list.



From:epp-dev-boun...@eclipse.org<mailto:epp-dev-boun...@eclipse.org> 
[mailto:epp-dev-boun...@eclipse.org] On Behalf Of Markus Knauer
Sent: Monday, June 18, 2018 11:24 AM
To: Eclipse Packaging Project mailto:epp-...@eclipse.org>>
Subject: Re: [epp-dev] Photon RC4 EPP packages



Hi Patrick,



I'm aware of the process for a respin... and right now I'm waiting, too, but 
haven't seen anything on any of the other mailing lists. My expectation is that 
we'll soon have a respin, first for the SimRel p2 repository, then for all the 
packages.



@Doug, is the Tools PMC going to forward this request to the Planning Council?



Thanks,

Markus







On 18 June 2018 at 16:49, Patrick Bänziger 
mailto:patrick.baenzi...@bsi-software.com>> 
wrote:

Hi Markus



Scout does not contain any incubation components.



Regarding testing: Will there be a respin now that Doug Schaefer requested one 
for CDT?  (and when?)

Because according to Wiki:SimRel/RelEng:How to do a 
respin<https://wiki.eclipse.org/SimRel/Simultaneous_Release_Engineering#How_to_do_a_re-spin>,
 the planning council should decide this, and I see nothing on their mailing 
list<https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/>.



If there is a respin, we’ll test the respun version – otherwise, we’ll have to 
test the version from Markus’ mail.



Regards,

Patrick



From:epp-dev-boun...@eclipse.org<mailto:epp-dev-boun...@eclipse.org>mailto:epp-dev-boun...@eclipse.org>>
 On Behalf Of Markus Knauer
Sent: Samstag, 16. Juni 2018 17:54
To: EPP Developer Mailing List mailto:epp-...@eclipse.org>>
Subject: [epp-dev] Photon RC4 EPP packages



Hi Package Maintainers,



here is the slightly delayed RC4 candidate:



  
https://ci.eclipse.org/packaging/job/photon.epp-tycho-build/340/artifact/org.eclipse.epp.packages/archive/



The following p2 repositories have been used to assemble the packages, and 
should be used for testing updates:

 http://download.eclipse.org/technology/epp/packages/photon/RC4
 http://download.eclipse.org/staging/photon/



This is the last RC unless there are stop ship bugs detected during quiet week. 
Please test it carefully and send your results to this mailing list until 
Tuesday.



In addition to the usual votes, I'm asking you to state that your package does 
not contain any parts from incubating projects. Or, if it does, please list 
them.



Thanks,

Markus

___
epp-dev mailing list
epp-...@eclipse.org<mailto:epp-...@eclipse.org>
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev



--



###
EclipseSource Group
Telefon: +49 721 664733-0 (UTC +1)
Telefax: +49 721 66473329

http://eclipsesource.com<http://eclipsesource.com/>

Innoopract Informationssysteme GmbH
Lammstrasse 21, 76133 Karlsruhe Germany
General Manager: Jochen Krause
Registered Office: Karlsruhe, Commercial Register Mannheim HRB 
107883

Re: [cross-project-issues-dev] [epp-dev] Photon RC4 EPP packages

[Doug Schaefer]

I'm on the PMC. Again, Alex, our rep, and the rest of the planning council 
should know about this by now.

BTW, every minute we wait, assuming the request is approved, pushes everything 
back.

Doug.

From: epp-dev-boun...@eclipse.org [mailto:epp-dev-boun...@eclipse.org] On 
Behalf Of Daniel Megert
Sent: Monday, June 18, 2018 11:39 AM
To: Eclipse Packaging Project 
Subject: Re: [epp-dev] Photon RC4 EPP packages

It's not about "watching". You have to go to your PMC and the PMC to the 
Planning Council.

Dani



From:    Doug Schaefer 
mailto:dschae...@blackberry.com>>
To:Eclipse Packaging Project 
mailto:epp-...@eclipse.org>>
Date:18.06.2018 17:33
Subject:Re: [epp-dev] Photon RC4 EPP packages
Sent by:epp-dev-boun...@eclipse.org<mailto:epp-dev-boun...@eclipse.org>



Not sure, I'm assuming the planning council including Alex is watching the 
cross projects list.



From:epp-dev-boun...@eclipse.org [mailto:epp-dev-boun...@eclipse.org] On Behalf 
Of Markus Knauer
Sent: Monday, June 18, 2018 11:24 AM
To: Eclipse Packaging Project mailto:epp-...@eclipse.org>>
Subject: Re: [epp-dev] Photon RC4 EPP packages



Hi Patrick,



I'm aware of the process for a respin... and right now I'm waiting, too, but 
haven't seen anything on any of the other mailing lists. My expectation is that 
we'll soon have a respin, first for the SimRel p2 repository, then for all the 
packages.



@Doug, is the Tools PMC going to forward this request to the Planning Council?



Thanks,

Markus







On 18 June 2018 at 16:49, Patrick Bänziger 
mailto:patrick.baenzi...@bsi-software.com>> 
wrote:

Hi Markus



Scout does not contain any incubation components.



Regarding testing: Will there be a respin now that Doug Schaefer requested one 
for CDT?  (and when?)

Because according to Wiki:SimRel/RelEng:How to do a 
respin<https://wiki.eclipse.org/SimRel/Simultaneous_Release_Engineering#How_to_do_a_re-spin>,
 the planning council should decide this, and I see nothing on their mailing 
list<https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/>.



If there is a respin, we'll test the respun version - otherwise, we'll have to 
test the version from Markus' mail.



Regards,

Patrick



From:epp-dev-boun...@eclipse.org<mailto:epp-dev-boun...@eclipse.org>mailto:epp-dev-boun...@eclipse.org>>
 On Behalf Of Markus Knauer
Sent: Samstag, 16. Juni 2018 17:54
To: EPP Developer Mailing List mailto:epp-...@eclipse.org>>
Subject: [epp-dev] Photon RC4 EPP packages



Hi Package Maintainers,



here is the slightly delayed RC4 candidate:



  
https://ci.eclipse.org/packaging/job/photon.epp-tycho-build/340/artifact/org.eclipse.epp.packages/archive/



The following p2 repositories have been used to assemble the packages, and 
should be used for testing updates:

 http://download.eclipse.org/technology/epp/packages/photon/RC4
 http://download.eclipse.org/staging/photon/



This is the last RC unless there are stop ship bugs detected during quiet week. 
Please test it carefully and send your results to this mailing list until 
Tuesday.



In addition to the usual votes, I'm asking you to state that your package does 
not contain any parts from incubating projects. Or, if it does, please list 
them.



Thanks,

Markus

___
epp-dev mailing list
epp-...@eclipse.org<mailto:epp-...@eclipse.org>
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev



--



###
EclipseSource Group
Telefon: +49 721 664733-0 (UTC +1)
Telefax: +49 721 66473329

http://eclipsesource.com<http://eclipsesource.com/>

Innoopract Informationssysteme GmbH
Lammstrasse 21, 76133 Karlsruhe Germany
General Manager: Jochen Krause
Registered Office: Karlsruhe, Commercial Register Mannheim HRB 
107883___
epp-dev mailing list
epp-...@eclipse.org<mailto:epp-...@eclipse.org>
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-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] Request for rebuild RC4 to pick up CDT

[Doug Schaefer]

Any objections?

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer
Sent: Sunday, June 17, 2018 1:14 PM
To: Cross project issues 
Cc: Eclipse Packaging Project 
Subject: [cross-project-issues-dev] Request for rebuild RC4 to pick up CDT

Hey gang,

I discovered a blocking bug when starting to write a CDT article about Photon. 
It breaks CDT's serial launching capability with the Terminal open on the same 
port. CDT does a pause and resume serial port so that the launch can get access 
to it. This feature is used when working with microcontrollers including all 
the Arduino's.

Also, for the article I've fixed CDT's scanner discovery for an issue that 
raised its head when working with Espressif's ESP-IDF SDK used to program the 
ESP32, another inexpensive microcontroller and the example for the article.

Bug are here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=534286
https://bugs.eclipse.org/bugs/show_bug.cgi?id=535972

The first one is actually a revert of a commit made three weeks ago that caused 
the serial port failure.

I thus request a respin of RC4 simrel and C++ package to pick up the CDT build 
with fixes to these. The simrel files have already been updated and merged.

Thanks and apologies,
Doug.
___
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] Request for rebuild RC4 to pick up CDT

[Doug Schaefer]

Hey gang,

I discovered a blocking bug when starting to write a CDT article about Photon. 
It breaks CDT's serial launching capability with the Terminal open on the same 
port. CDT does a pause and resume serial port so that the launch can get access 
to it. This feature is used when working with microcontrollers including all 
the Arduino's.

Also, for the article I've fixed CDT's scanner discovery for an issue that 
raised its head when working with Espressif's ESP-IDF SDK used to program the 
ESP32, another inexpensive microcontroller and the example for the article.

Bug are here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=534286
https://bugs.eclipse.org/bugs/show_bug.cgi?id=535972

The first one is actually a revert of a commit made three weeks ago that caused 
the serial port failure.

I thus request a respin of RC4 simrel and C++ package to pick up the CDT build 
with fixes to these. The simrel files have already been updated and merged.

Thanks and apologies,
Doug.
___
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] [cdt-dev] [tm-dev] TM Terminal and RSE releases for Photon (was: Correct repo for CDT to be referring to)

[Doug Schaefer]

CDT users use TM regularly, especially for Arduino and other embedded targets. 
Haven’t seen anything drastically broken so we haven’t done anything to it. I 
am a committer as well if a patch comes in. Other than that it’s in deep 
maintenance mode.

Doug.

From: cdt-dev-boun...@eclipse.org [mailto:cdt-dev-boun...@eclipse.org] On 
Behalf Of Nick Boldt
Sent: Monday, June 11, 2018 9:25 AM
To: TM project developer discussions 
Cc: Cross project issues ; CDT General 
developers list. 
Subject: Re: [cdt-dev] [tm-dev] TM Terminal and RSE releases for Photon (was: 
Correct repo for CDT to be referring to)

I stepped in recently to do releng for tm.rse & update it to build against 
Photon (because JBoss Tools requires it) but as yet I haven't done anything for 
tm.terminal, as I believe CDT Doug's been running the show there (because CDT 
requires it).

If he's OK with me stepping in to help there too, I can find time this week to 
make sure there are new tm.terminal and tm.rse builds based on Photon.0.RC4. 
Can anyone on this list commit to smoke testing the builds? Other than "the 
tests pass in Jenkins" and "I can install everything from the update sites" I 
don't know how to verify the builds' contents are working as expected.

Nick

On Mon, Jun 11, 2018 at 9:06 AM, Jonah Graham 
mailto:jo...@kichwacoders.com>> wrote:
Ni Nick,

Thanks for looking into this. I (on behalf of CDT) am not publishing the TM 
builds, simply consuming them when I noticed the discrepancy. Are you running 
releng for TM at the moment, or is this a continuing case of TM lacking the 
devs it needs?

AFAICT, the correct TM is being published, but from an unstable URL, so end 
users are getting the right version.

Jonah



~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com


On Mon, 11 Jun 2018 at 13:49, Nick Boldt 
mailto:nbo...@redhat.com>> wrote:
The nightly site contains something newer (2018/03/14) that the last milestone 
site (2018/03/12).

You can use p2 browser [1] to explore the sites [2] and pick an IU to 
investigate versions:

[1] https://github.com/nickboldt/p2-browser

[2] https://imagebin.ca/v/44v9BWPVZFu6

Given we're at RC4, it would probably be wise to release the 03/14 build to the 
milestone site.

I can cobble a job together to do the publishing, unless you already have 
something you're using to publish updates.

I notice the last tm.terminal build [3] was based on Photon.0.M6 so we should 
probably update that & rebuild it too to make sure it still works against 
Photon.RC4.

[3] https://ci.eclipse.org/tm/view/terminal/job/terminal-master/

I suppose I should also do a TM.RSE release [4] this week too as the last build 
was back in March, also based on earlier Photon deps.

[4] https://ci.eclipse.org/tm/view/rse/job/rse_master/



On Sat, Jun 9, 2018 at 6:13 PM, Jonah Graham 
mailto:jo...@kichwacoders.com>> wrote:
Hi TM folk,

I am doing a review of CDT's target 
platform
 for the 9.5 branch (in preparation for Photon release) and I came across a 
minor anomaly I wanted to resolve.

At the moment CDT uses a build from 2 days before what TM is contributing in 
the simrel.

CDT uses: http://download.eclipse.org/tm/terminal/updates/4.4milestones/
Simrel uses: http://download.eclipse.org/tm/terminal/builds/development/nightly/

I don't really want to have CDT point at a development/nightly build on the 9.5 
branch. Is there any difference between the two. Does TM plan to publish a URL 
suitable for building against Photon?

Thanks,
Jonah

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

___
tm-dev mailing list
tm-...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/tm-dev



--

Nick Boldt

Principal Software Engineer, RHCSA

Productization Lead :: JBoss Tools & Dev Studio

IM: @nickboldt / @nboldt / http://nick.divbyzero.com
[https://www.redhat.com/files/brand/email/sig-redhat.png]

TRIED. TESTED. TRUSTED.

@ @redhatnews  Red 
Hat



“The Only Thing That Is Constant Is Change” - Heraclitus
___
tm-dev mailing list
tm-...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/tm-dev

___
tm-dev mailing list
tm-...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/tm-dev



--

Nick Boldt

Principal Software 

Re: [cross-project-issues-dev] Corrosion in Photon

[Doug Schaefer]

You need to make that request through your PMC first and they will have to take 
it to the planning council.

Doug.

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Lucas Bullen
Sent: Tuesday, April 17, 2018 11:20 AM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Corrosion in Photon

This is a request for Corrosion to join the Photon Simultaneous release. Please 
excuse the late request, the project joined Eclipse at M4 but is required 
within the SimRel for Corrosion to be released through EPP to allow for a 
lighter weight IDE for Rust developers and to offer the first 
one-click-download Rust IDE.

Project Name: Eclipse Corrosion
Project Info:
Eclipse Corrosion provides development tools for Rust and Cargo inside the 
Eclipse IDE.
More info can be found in the initial project proposal: 
https://projects.eclipse.org/projects/tools.corrosion/reviews/creation-review

Release Record: https://projects.eclipse.org/projects/tools.corrosion/governance
Intended Release to join Photon SimRel: 0.1.0 
(https://projects.eclipse.org/projects/tools.corrosion/releases/0.1)
Offset: +3

--

Lucas Bullen

Software Engineering Intern

Red Hat



90 Eglinton Ave E #502,

Toronto, ON M4P 2Y3

lbul...@redhat.com
[https://www.redhat.com/files/brand/email/sig-redhat.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] Migration from Hudson to Jenkins is complete

[Doug Schaefer]

+1! Thanks Fred!

> -Original Message-
> From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-
> issues-dev-boun...@eclipse.org] On Behalf Of Denis Roy
> Sent: Thursday, March 15, 2018 11:42 AM
> To: cross-project-issues-dev@eclipse.org
> Subject: Re: [cross-project-issues-dev] Migration from Hudson to Jenkins is
> complete
> 
> Great work, Fred!
> 
> Denis
> 
> 
> 
> On 2018-03-15 07:24 AM, Frederic Gurr wrote:
> > Hi,
> >
> > As of March 1st, 2018, all 180 Hudson instances (HIPPs) have been
> > migrated to a recent LTS version of Jenkins. There were a few minor
> > (and
> > expected) hiccups, but in general it went pretty smoothly.
> >
> > If you still find an issue that might be related to the migration,
> > please file a Bugzilla issue.
> >
> > We are currently in the process of bringing the build infrastructure
> > to the next level, to better utilize the available hardware and reduce
> > maintenance efforts. Expect to hear more details about this in the
> > near future.
> >
> > Thanks for your patience.
> >
> >
> > Regards,
> >
> > Fred
> >
> 
> ___
> 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] Committer for simrel

[Doug Schaefer]

Thanks!

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

Doug.

> -Original Message-
> From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-
> issues-dev-boun...@eclipse.org] On Behalf Of Zoltán Ujhelyi
> Sent: Tuesday, February 20, 2018 9:59 AM
> To: Cross project issues <cross-project-issues-dev@eclipse.org>
> Subject: Re: [cross-project-issues-dev] Committer for simrel
> 
> Hi,
> 
> simply open a bug at Community/Cross-projects and state that you want to have
> commit rights. For more details, see
> https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Push
> ing_your_changes
> 
> Best regards,
> Zoltán
> 
> -- Zoltán Ujhelyi
> 
> Eclipse Technologies Expert
> IncQueryLabs Ltd.
> 
> > On 2018. Feb 20., at 15:55, Doug Schaefer <dschae...@blackberry.com>
> wrote:
> >
> > Hey gang,
> >
> > Jonah is helping CDT with releng. Can someone remind me of the process to
> get him nominated as a committer to give him write access to the simrel
> aggregator files?
> >
> > Thanks
> > Doug.
> > ___
> > 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] SimRel - TM contribution has been disabled

[Doug Schaefer]

Again, this discussion needs to happen on the tm-dev list.

Doug.

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Wayne Beaton
Sent: Tuesday, February 13, 2018 9:26 AM
To: Cross project issues <cross-project-issues-dev@eclipse.org>
Cc: Kaloyan Raev <kaloya...@zend.com>
Subject: Re: [cross-project-issues-dev] SimRel - TM contribution has been 
disabled

Strictkly speaking, the "leadership chain" can decide to add or remove 
committers if the project is determined to be dysfunctional. The leadership 
chain includes the PMC. They'd have to ask me to initiate this exceptional 
process...

Wayne

On Tue, Feb 13, 2018 at 7:00 AM, Lars Vogel 
<lars.vo...@vogella.com<mailto:lars.vo...@vogella.com>> wrote:
> So... Who'd like to nominate me? :)

I'm not a TM committer. Doug, or Kaloyan, can you start the nomination?

Otherwise, I think EMO could give you access if TM is considered as an
abandoned project.

On Tue, Feb 13, 2018 at 12:11 AM, Nick Boldt 
<nickbo...@gmail.com<mailto:nickbo...@gmail.com>> wrote:
> Considering the list of open TM/RSE gerrits [1] include one that's a 1-line
> fix for JDK 9 support, and is 2 weeks old without feedback (I just posted a
> +1 on it)... Doug's right, there may be no one to receive my PRs to updated
> RSE to work with Photon.
>
> [1] https://git.eclipse.org/r/p/tm/org.eclipse.tm
>
> I also commented on one that's over 5 years old and unmerged. That one and
> all those older I suspect should be abandoned as they can't (or shouldn't)
> be merged.
>
> If Kaloyan, Lars or any past TM committers [2] want to vote me in, I'll
> clean up the open gerrits and get RSE building again in JIPP.
>
> [2] https://projects.eclipse.org/projects/tools.tm/who
>
> So... Who'd like to nominate me? :)
>
> --
>
> Nick Boldt :: http://nick.divbyzero.com
> FB, IG, Twitter, G+, LinkedIn, Freenode: @nickboldt
> WhatsApp: +57 311 530 2074<tel:%2B57%20311%20530%202074> or +1 647 899 
> 9879<tel:%2B1%20647%20899%209879>
>
>
> On Feb 12, 2018 10:16 AM, "Lars Vogel" 
> <lars.vo...@vogella.com<mailto:lars.vo...@vogella.com>> wrote:
>
> I suggest to nominate Nick as TM committer
>
> Am 12.02.2018 16:06 schrieb "Doug Schaefer" 
> <dschae...@blackberry.com<mailto:dschae...@blackberry.com>>:
>>
>> Nick, who specifically on that “team” do you think should get those
>> changes in for you? To help, here is the commit log from the git repo.
>>
>>
>>
>> http://git.eclipse.org/c/tm/org.eclipse.tm.git/log/
>>
>>
>>
>> Kaloyan Raev is the only active committer and from his note earlier in
>> this chain, he has removed the dependency from the projects he works on.
>>
>>
>>
>> We really need to be crystal clear at this point what the plan is.
>>
>>
>>
>> Doug.
>>
>>
>>
>> From: 
>> cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
>> [mailto:cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>]
>>  On Behalf Of Nick
>> Boldt
>> Sent: Monday, February 12, 2018 9:49 AM
>> To: issues, Cross project 
>> <cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
>> Subject: Re: [cross-project-issues-dev] SimRel - TM contribution has been
>> disabled
>>
>>
>>
>> AFAIK it's out.
>>
>>
>>
>> But if I find time to submit the changes from my/Rob's github fork as
>> gerrit review(s) back to the master fork on 
>> git.eclipse.org<http://git.eclipse.org>, that team can
>> evaluate it, merge it, and maybe decide they want to be included for M6.
>> Then it'll be up to the Planning Council to approve the late addition.
>>
>>
>>
>> At least that's my interpretation of the rules. EMO might have a different
>> view. :)
>>
>>
>>
>> Nick
>>
>> --
>>
>> Nick Boldt
>> Senior Software Engineer, RHCSA
>> Productization Lead :: JBoss Tools & Dev Studio
>> IM: @nickboldt / @nboldt / http://nick.divbyzero.com
>> Sent from my Android phone
>>
>>
>>
>> On Feb 8, 2018 11:29 AM, "Simon Bernard" 
>> <sbern...@sierrawireless.com<mailto:sbern...@sierrawireless.com>>
>> wrote:
>>
>> Hi,
>>
>> Sry for the delay, I re-enabled LDT removing ldt.remote feature which
>> depends on RSE.
>> So this should be ok for photon M6.
>>
>> I'm a bit confuse. Will RSE be reintegrated o

Re: [cross-project-issues-dev] SimRel - TM contribution has been disabled

[Doug Schaefer]

Nick, who specifically on that “team” do you think should get those changes in 
for you? To help, here is the commit log from the git repo.

http://git.eclipse.org/c/tm/org.eclipse.tm.git/log/

Kaloyan Raev is the only active committer and from his note earlier in this 
chain, he has removed the dependency from the projects he works on.

We really need to be crystal clear at this point what the plan is.

Doug.

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Nick Boldt
Sent: Monday, February 12, 2018 9:49 AM
To: issues, Cross project 
Subject: Re: [cross-project-issues-dev] SimRel - TM contribution has been 
disabled

AFAIK it's out.

But if I find time to submit the changes from my/Rob's github fork as gerrit 
review(s) back to the master fork on git.eclipse.org, 
that team can evaluate it, merge it, and maybe decide they want to be included 
for M6. Then it'll be up to the Planning Council to approve the late addition.

At least that's my interpretation of the rules. EMO might have a different 
view. :)

Nick
--

Nick Boldt
Senior Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
IM: @nickboldt / @nboldt / http://nick.divbyzero.com
Sent from my Android phone

On Feb 8, 2018 11:29 AM, "Simon Bernard" 
> wrote:
Hi,

Sry for the delay, I re-enabled LDT removing ldt.remote feature which depends 
on RSE.
So this should be ok for photon M6.

I'm a bit confuse. Will RSE be reintegrated or is  it officially and definitely 
not part of Photon ?

Thx,

Simon


Le 01/02/2018 à 12:22, Frederic Gurr a écrit :
Hi,

Thanks to Kaloyan, Dawid and Eugene for fixing and re-enabling the
contributions of DLTK, PDT and TCF.

The only contribution missing is LDT.
Since it's already past the +3 window, LDT will miss Photon M5.
Hopefully they can rejoin for M6.

Regards,

Fred

___
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] SimRel - TM contribution has been disabled

[Doug Schaefer]

You're right, I'll leave it to the active committers to decide. And this 
discussion should be happening on the tm-dev list so they see it.

Sent from my BlackBerry - the most secure mobile device - via the Rogers Network
From: mist...@redhat.com
Sent: January 31, 2018 5:33 PM
To: cross-project-issues-dev@eclipse.org
Reply-to: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] SimRel - TM contribution has been 
disabled




On Wed, Jan 31, 2018 at 11:14 PM, Doug Schaefer 
<dschae...@blackberry.com<mailto:dschae...@blackberry.com>> wrote:
Does anyone want these contributions to keep RSE alive?

I don't think the opinion of others should be used as a criterion here. The 
thing is that if Nick, Rob or whoever have authored good patches, it's still 
better to contribute them into the project, independently of what others want 
to do or not with RSE. No-one is allowed to claim that a project is dead if it 
still has contributors/contributions. If the patches are proposed and seem good 
but don't get merged for other non-technical reason and contributors are still 
interested in getting those patches merged, then it's worth an escalation plan 
to turn contributors into committers.
In general, having people authoring commits can be seen as a sign that at least 
those who did the work probably have interest in authoring the commits, ie 
keeping RSE alive in that case. So to me, whenever there is a contribution, it 
shows that the project can still be perceived as alive and that no other 
discussion is necessary before applying the typical EDP processes to make sure 
project can be as successful as contributors can make it.
To sum up, we don't need to discuss RSE state any more, the patches authored by 
Rob and Nick can be a sufficient sign that RSE is still alive and we just have 
to make sure the efforts stored on a GitHub branch can be turned into activity 
in the origin code base if committers want it.

Cheers,
___
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] Many projects have not yet opted in to participate in Eclipse Photon

[Doug Schaefer]

I am purposely leaving RSE out on its own. Greg's org.eclipse.remote better 
suits our needs in CDT and will be going forward with that. RSE needs a new 
owner, or archive.

Doug.

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Martin 
Oberhuber
Sent: Tuesday, December 19, 2017 6:35 AM
To: Cross project issues 
Subject: Re: [cross-project-issues-dev] Many projects have not yet opted in to 
participate in Eclipse Photon

Regarding Target Management, IIRC there is a plan moving the Terminal to the 
CDT.

But what about RSE?
Some packages include it now (PHP, JEE, C/C++ as far as I know)...

I am a TM committer, but I can not personally support TM on the release train.

Martin


On 15 Dec 2017, at 21:01, Wayne Beaton 
>
 wrote:

By way of background, we introduced the requirement that projects publicly 
state their intent to 
participate
 in each release to ensure that everybody is actually paying attention. In the 
past, we've had to scramble to sort out last minute issues because (some) 
project teams hadn't engaged. Participation in the simultaneous release 
requires some ongoing investment of time and energy from those projects that 
join in.

The deadline for stating intent to join the Eclipse Photon simultaneous release 
is EOB today. After that, the rules state that projects must work through their 
PMC to have the Eclipse Planning Council grant an exception to join after the 
deadline.

I am pretty confident, however, that if you state your intent on this list by 
mid-week next week, the Planning Council will accept it. Please, get this done.

Any project that has not declared an intent to participate will be removed from 
the aggregation build prior to the M5 release. I'll work with Fred and Mikael 
to deactivate builds early in the new year.

AFAICT, the following projects have not stated their intention to participate.

  *   Eclipse EGerrit
  *   Eclipse e(fx)clipse
  *   Eclipse Parallel Tools Platform (PTP)
  *   Eclipse Sapphire
  *   Eclipse Sphinx
  *   Eclipse Target Management
  *   Eclipse Communication Framework
  *   Eclipse XWT
  *   Eclipse PMF
  *   Eclipse Orion
  *   Eclipse Accessibility Tools Framework
  *   Eclipse ATL
  *   Eclipse Subversive SVN Team Provider
  *   Eclipse Data Tools Platform
If you represent one of these projects and have chosen not to participate, 
please let the group know.

If you're listed here in error, I apologise. Please send me a harshly worded 
note pointing out my omission.

I am working with the Eclipse Data Tools Platform, so we'll likely get that 
resolved shortly.

The Eclipse Subversive team has indicated that they can no longer support the 
project, so we're going to have to sort out what (if anything) to do about that.

Since I'm pretty sure that the Eclipse Packaging Project is paying attention 
(and I am a committer on the project), I've created a 4.8 
release
 at +4 (consider this the project's declaration of participation).

Thanks for your attention,

Wayne
--
Wayne Beaton
Director of Open Source Projects
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

___
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] Many projects have not yet opted in to participate in Eclipse Photon

[Doug Schaefer]

That's the plan. Thanks Greg! Good to see PTP in the release.

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Greg Watson
Sent: Monday, December 18, 2017 4:12 PM
To: Cross project issues 
Subject: Re: [cross-project-issues-dev] Many projects have not yet opted in to 
participate in Eclipse Photon

PTP will be participating in Photon with release 9.2 offset +3. I presume the 
remote project will have been transferred to CDT by then.

Regards,
Greg


On Dec 15, 2017, at 3:01 PM, Wayne Beaton 
>
 wrote:

By way of background, we introduced the requirement that projects publicly 
state their intent to 
participate
 in each release to ensure that everybody is actually paying attention. In the 
past, we've had to scramble to sort out last minute issues because (some) 
project teams hadn't engaged. Participation in the simultaneous release 
requires some ongoing investment of time and energy from those projects that 
join in.

The deadline for stating intent to join the Eclipse Photon simultaneous release 
is EOB today. After that, the rules state that projects must work through their 
PMC to have the Eclipse Planning Council grant an exception to join after the 
deadline.

I am pretty confident, however, that if you state your intent on this list by 
mid-week next week, the Planning Council will accept it. Please, get this done.

Any project that has not declared an intent to participate will be removed from 
the aggregation build prior to the M5 release. I'll work with Fred and Mikael 
to deactivate builds early in the new year.

AFAICT, the following projects have not stated their intention to participate.

  *   Eclipse EGerrit
  *   Eclipse e(fx)clipse
  *   Eclipse Parallel Tools Platform (PTP)
  *   Eclipse Sapphire
  *   Eclipse Sphinx
  *   Eclipse Target Management
  *   Eclipse Communication Framework
  *   Eclipse XWT
  *   Eclipse PMF
  *   Eclipse Orion
  *   Eclipse Accessibility Tools Framework
  *   Eclipse ATL
  *   Eclipse Subversive SVN Team Provider
  *   Eclipse Data Tools Platform
If you represent one of these projects and have chosen not to participate, 
please let the group know.

If you're listed here in error, I apologise. Please send me a harshly worded 
note pointing out my omission.

I am working with the Eclipse Data Tools Platform, so we'll likely get that 
resolved shortly.

The Eclipse Subversive team has indicated that they can no longer support the 
project, so we're going to have to sort out what (if anything) to do about that.

Since I'm pretty sure that the Eclipse Packaging Project is paying attention 
(and I am a committer on the project), I've created a 4.8 
release
 at +4 (consider this the project's declaration of participation).

Thanks for your attention,

Wayne
--
Wayne Beaton
Director of Open Source Projects
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

___
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] Can DTP join EGit in Oxygen.2 respin?

[Doug Schaefer]

I did say “planning”. ;).

As projects run out of committers, we need to make sure everyone is aware of 
the situation and so they can consider how it affects them.

Doug.

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Wayne Beaton
Sent: Monday, December 18, 2017 2:32 PM
To: Cross project issues <cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?

No. We'll start that process in January in preparation for the M5 build.

Besides, removing it breaks Web Tools (at least).

I'm pretty sure that we have a volunteer to take over releng.

Wayne

On Dec 18, 2017 9:48 AM, "Doug Schaefer" 
<dschae...@blackberry.com<mailto:dschae...@blackberry.com>> wrote:
We should probably start planning on the removal of DTP now. It’s not clear it 
has the resources to even do builds going forward.

Doug.

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 
[mailto:cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>]
 On Behalf Of Daniel Megert
Sent: Monday, December 18, 2017 4:48 AM
To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Subject: Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?

It's good enough to just do a build. The API was deprecated for ten years 
already. After removing it for Oxygen (4.7) a simple build would have failed 
with a compile error.

Dani



From:"Torkild U. Resheim" 
<torki...@gmail.com<mailto:torki...@gmail.com>>
To:Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Date:16.12.2017 21:11
Subject:Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 
respin?
Sent by:
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>




Yes, I think that’s a good idea Stephan. One could possibly set up the build to 
fail when using deprecated API, in order to get an early warning. I’m not aware 
of a way of making Tycho do so though. I guess having a no-warnings policy and 
set the compiler up to fail on warnings is an option.

Best regards,
Torkild

> 16. des. 2017 kl. 17:54 skrev Stephan Herrmann 
> <stephan.herrm...@berlin.de<mailto:stephan.herrm...@berlin.de>>:
>
> Another option could be: even "inactive" projects could be required,
> to perform builds against each SimRel milestone, even when contributing
> a previous version. This should ensure that code still works (compiles
> and passes tests) against updated dependencies.
>
> I don't think this should be much of a burden on "maintainers".
>
> Stephan

[attachment "signature.asc" deleted by Daniel Megert/Zurich/IBM]
___
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<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

Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?

[Doug Schaefer]

We should probably start planning on the removal of DTP now. It's not clear it 
has the resources to even do builds going forward.

Doug.

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Daniel Megert
Sent: Monday, December 18, 2017 4:48 AM
To: Cross project issues 
Subject: Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?

It's good enough to just do a build. The API was deprecated for ten years 
already. After removing it for Oxygen (4.7) a simple build would have failed 
with a compile error.

Dani



From:"Torkild U. Resheim" 
>
To:Cross project issues 
>
Date:16.12.2017 21:11
Subject:Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 
respin?
Sent by:
cross-project-issues-dev-boun...@eclipse.org




Yes, I think that's a good idea Stephan. One could possibly set up the build to 
fail when using deprecated API, in order to get an early warning. I'm not aware 
of a way of making Tycho do so though. I guess having a no-warnings policy and 
set the compiler up to fail on warnings is an option.

Best regards,
Torkild

> 16. des. 2017 kl. 17:54 skrev Stephan Herrmann 
> >:
>
> Another option could be: even "inactive" projects could be required,
> to perform builds against each SimRel milestone, even when contributing
> a previous version. This should ensure that code still works (compiles
> and passes tests) against updated dependencies.
>
> I don't think this should be much of a burden on "maintainers".
>
> Stephan

[attachment "signature.asc" deleted by Daniel Megert/Zurich/IBM]
___
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 Photon opt-in deadline is December 15.

[Doug Schaefer]

CDT 9.5 in for Photon. We are offset +1.

https://projects.eclipse.org/projects/tools.cdt/releases/9.5.0

Doug.

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Wayne Beaton
Sent: Wednesday, November 29, 2017 1:19 PM
To: Cross project issues 
Subject: [cross-project-issues-dev] Eclipse Photon opt-in deadline is December 
15.

The deadline to opt in for Eclipse Photon is December 15/2016.

The process established by the Eclipse Planning Council is that all projects 
that intend to participate in the release must announce their intent on this 
list.

Your announcement must include a link to the release record and state the 
planned offset. This is all explained in the documentation.

https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#State_intent_early_.28M4.29

This requirement to state intent is primarily to make sure that project teams 
are paying attention. While it's true that I can probably hunt down last year's 
participants and just add them to the list, doing so would defeat this primary 
goal.

Many projects have already declared their intent.

https://projects.eclipse.org/releases/photon

If your project is not listed, or is missing release information, please 
announce your intent soon. If you're dropping out let us know that as well.

Note that in early 2018, we will start disabling projects that do not state 
their intent from the aggregation build.

Let me know if you have any questions.

Wayne


___
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] Asterisk shutdown, Jan 5th 2018

[Doug Schaefer]

Thanks Matt, we're very much looking forward to this.

On recent calls it appears the dial in numbers were not working to Asterisk. Is 
that working now? If not, for a lot of us, Asterisk is already shutdown.

Thanks!
Doug.

-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of 
Webmaster(Matt Ward)
Sent: Monday, November 27, 2017 11:17 AM
To: Cross project issues 
Subject: [cross-project-issues-dev] Asterisk shutdown, Jan 5th 2018

Hi Everyone,

  As some of you may already know our Asterisk service has been failing us 
recently, and we have decided to replace it with service from Zoom.us .  The 
shutdown date for Asterisk is January 5th 2018.

Due to the way in which Zoom works, and is priced we're changing how we provide 
bridges.  Unlike Asterisk where we provided a bridge on a per project basis, we 
will be providing Zoom accounts(bridges) to our top level PMCs with the 
expectation that they will help co-ordinate the calls for any sub-projects they 
are responsible for.

Several PMCs are currently testing this service, and we will be sending out 
more account details as they become available.

If you have any questions please let me know.

-Matt.


___
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] Bug tracker for Jsch

[Doug Schaefer]

That's my biggest fear depending on projects like that. And we do have a huge 
dependency on SSH communication in Eclipse, not only for EGit but the SSH 
Terminal as well and future work CDT's planning for remote builds and 
launching. Would be good to get this or something like this under our control.

Doug.

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Gunnar 
Wagenknecht
Sent: Wednesday, November 15, 2017 2:23 AM
To: Cross project issues 
Subject: Re: [cross-project-issues-dev] Bug tracker for Jsch

It looks like the JSch project is in a poor state.

It has been a one-developer project. The developer did not make any 
contributions on GitHub over the last year.
https://github.com/ymnk

At this point it looks like your best bet is a fork and fixing the issues 
yourself or consider migrating to a more active project.
https://github.com/hierynomus/sshj
http://mina.apache.org/sshd-project/sources.html

-Gunnar

--
Gunnar Wagenknecht
gun...@wagenknecht.org, http://guw.io/





On Nov 15, 2017, at 08:02, Matthias Sohn 
> wrote:

Does anybody know where to report bugs for the Jsch project?

Thomas implemented several workarounds for Jsch bugs in JGit:
* "Work around a Jsch bug: ensure the user name is set from URI" [1]
* "Yet another work-around for a Jsch bug: timeouts" [2]

We would like to report these Jsch bugs to its maintainers in order to get them
fixed upstream but we struggle to find the bug tracker for Jsch. We also tried
to cc Atsuhiko Yamanaka on bug 526778 but so far we got no response.

We found this bugtracker in SourceForge [3] but aren't sure if that's correct 
since
all bugs raised there in the last years didn't get any response and the last bug
was closed back in 2013. So it looks like this bug tracker was abandoned.
I sent an email to JCraft (the company sponsoring the Jsch development) in
order to find out where we can report bugs but this email bounced.

[1]
https://git.eclipse.org/r/#/c/111359/
https://bugs.eclipse.org/bugs/show_bug.cgi?id=526778

[2]
https://git.eclipse.org/r/#/c/111421/
https://bugs.eclipse.org/bugs/show_bug.cgi?id=526867

[3] https://sourceforge.net/p/jsch/bugs/

-Matthias
___
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] Build Schedule for Oxygen.1 RC4?

[Doug Schaefer]

I was just wondering what the build schedule is for Oxygen.1 RC4. I have 
updated the CDT bits and I want to make sure they get in. They're not in the 
build that's currently running.

Thanks,
Doug.
___
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] Mac signing down?

[Doug Schaefer]

OK, cool. Thanks Denis and Matt and Mikael!

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Denis Roy
Sent: Monday, September 11, 2017 1:31 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Mac signing down?


We're having issues with the Mac machine doing the signing. Matt is in the data 
centre now swapping the machine to a different one, and we're setting up better 
services to ensure Mac signing (and Mac tests) are more reliable.

Mac signing will return soon, in all its glory.

Apologies for the inconvenience.



Denis

On 11/09/17 01:16 PM, Doug Schaefer wrote:
I’m still not clear on what this means. Does that mean Mac signing is now a 
manual process? Do I need to create a bug for every build we do? Or is that now 
unrealistic?

Thanks,
Doug.

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mikaël 
Barbero
Sent: Monday, September 11, 2017 12:43 PM
To: Cross project issues 
<cross-project-issues-dev@eclipse.org><mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] Mac signing down?

Hi Doug,

You should deactivate the mac signing for now. If you need some mac app to be 
signed, let us know on bugzilla CBI / signing 
service<https://bugs.eclipse.org/bugs/enter_bug.cgi?product=CBI=signing-service>.

See 
https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14725.html 
for details.

Cheers,

--
Mikaël Barbero - Eclipse Foundation
IT Services - Release Engineering
 (+33) 642 028 039
mikael.barb...@eclipse-foundation.org<mailto:mikael.barb...@eclipse-foundation.org>
 @mikbarbero

Le 11 sept. 2017 à 18:34, Doug Schaefer 
<dschae...@blackberry.com<mailto:dschae...@blackberry.com>> a écrit :

Hey gang,

I’m getting a failure on CDT’s build. We have a product we build for debugging 
workflows and it failed during the Mac signing. I noticed Dani bring up 
something similar on the epp-dev list. Is there someone looking at this?

Thanks!
Doug

12:25:54  Server response has been saved to 
'/jobs/genie.cdt/cdt-master/workspace/debug/org.eclipse.cdt.debug.application.product/target/products/org.eclipse.cdt.debug.application.product/macosx/cocoa/x86_64/cdt-stand-alone-debugger.app_1185177675979710469.zip-2803754418407502334-OSXAppSigner.log'
12:29:24  [WARNING] [Mon Sep 11 12:29:24 EDT 2017] HTTP request failed.
12:29:24  HTTP Error 503 (reason: Service Temporarily Unavailable)
12:29:24  
12:29:24  
12:29:24  503 Service Temporarily Unavailable
12:29:24  
12:29:24  Service Temporarily Unavailable
12:29:24  The server is temporarily unable to service your
12:29:24  request due to maintenance downtime or capacity
12:29:24  problems. Please try again later.
12:29:24  

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

--
Denis Roy
Director, IT Services
Eclipse Foundation, Inc. -- http://www.eclipse.org/
Office: 613.224.9461 x224 (Eastern time)
denis@eclipse-foundation.org<mailto:denis@eclipse-foundation.org>
@droy_eclipse
___
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] Mac signing down?

[Doug Schaefer]

I’m still not clear on what this means. Does that mean Mac signing is now a 
manual process? Do I need to create a bug for every build we do? Or is that now 
unrealistic?

Thanks,
Doug.

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mikaël 
Barbero
Sent: Monday, September 11, 2017 12:43 PM
To: Cross project issues <cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] Mac signing down?

Hi Doug,

You should deactivate the mac signing for now. If you need some mac app to be 
signed, let us know on bugzilla CBI / signing 
service<https://bugs.eclipse.org/bugs/enter_bug.cgi?product=CBI=signing-service>.

See 
https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14725.html 
for details.

Cheers,

--
Mikaël Barbero - Eclipse Foundation
IT Services - Release Engineering
 (+33) 642 028 039
 
mikael.barb...@eclipse-foundation.org<mailto:mikael.barb...@eclipse-foundation.org>
 @mikbarbero

Le 11 sept. 2017 à 18:34, Doug Schaefer 
<dschae...@blackberry.com<mailto:dschae...@blackberry.com>> a écrit :

Hey gang,

I’m getting a failure on CDT’s build. We have a product we build for debugging 
workflows and it failed during the Mac signing. I noticed Dani bring up 
something similar on the epp-dev list. Is there someone looking at this?

Thanks!
Doug

12:25:54  Server response has been saved to 
'/jobs/genie.cdt/cdt-master/workspace/debug/org.eclipse.cdt.debug.application.product/target/products/org.eclipse.cdt.debug.application.product/macosx/cocoa/x86_64/cdt-stand-alone-debugger.app_1185177675979710469.zip-2803754418407502334-OSXAppSigner.log'
12:29:24  [WARNING] [Mon Sep 11 12:29:24 EDT 2017] HTTP request failed.
12:29:24  HTTP Error 503 (reason: Service Temporarily Unavailable)
12:29:24  
12:29:24  
12:29:24  503 Service Temporarily Unavailable
12:29:24  
12:29:24  Service Temporarily Unavailable
12:29:24  The server is temporarily unable to service your
12:29:24  request due to maintenance downtime or capacity
12:29:24  problems. Please try again later.
12:29:24  

___
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

[cross-project-issues-dev] Mac signing down?

[Doug Schaefer]

Hey gang,

I'm getting a failure on CDT's build. We have a product we build for debugging 
workflows and it failed during the Mac signing. I noticed Dani bring up 
something similar on the epp-dev list. Is there someone looking at this?

Thanks!
Doug

12:25:54  Server response has been saved to 
'/jobs/genie.cdt/cdt-master/workspace/debug/org.eclipse.cdt.debug.application.product/target/products/org.eclipse.cdt.debug.application.product/macosx/cocoa/x86_64/cdt-stand-alone-debugger.app_1185177675979710469.zip-2803754418407502334-OSXAppSigner.log'
12:29:24  [WARNING] [Mon Sep 11 12:29:24 EDT 2017] HTTP request failed.
12:29:24  HTTP Error 503 (reason: Service Temporarily Unavailable)
12:29:24  
12:29:24  
12:29:24  503 Service Temporarily Unavailable
12:29:24  
12:29:24  Service Temporarily Unavailable
12:29:24  The server is temporarily unable to service your
12:29:24  request due to maintenance downtime or capacity
12:29:24  problems. Please try again later.
12:29:24  

___
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] LSP4E participation in Photon

[Doug Schaefer]

(This time with text.)

OK. That’s how we got away with CDT’s build cycle. Does point out a bit of a 
flaw with our offsets here. At the end of the day, we’ll build against your 
builds on Jenkins, not on what you post to the downloads area, to make sure we 
find out about changes early enough to recover.

Doug.


From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mickael 
Istria
Sent: Thursday, August 10, 2017 12:48 PM
To: Cross project issues 
Subject: Re: [cross-project-issues-dev] LSP4E participation in Photon

> Just curious, why +3?

Because the main dependency (LSP4J) is +2.

> We are thinking of adding a component that uses it to CDT to access the 
> clangd language server.
You can still use it. At the moment, LSP4E tries to keep focus on good forward 
and backward compatibility, so CDT shouldn't face so much issues on release if 
it's using LSP4E snapshots or milestones.
___
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] LSP4E participation in Photon

[Doug Schaefer]

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mickael 
Istria
Sent: Thursday, August 10, 2017 12:48 PM
To: Cross project issues 
Subject: Re: [cross-project-issues-dev] LSP4E participation in Photon

> Just curious, why +3?

Because the main dependency (LSP4J) is +2.

> We are thinking of adding a component that uses it to CDT to access the 
> clangd language server.
You can still use it. At the moment, LSP4E tries to keep focus on good forward 
and backward compatibility, so CDT shouldn't face so much issues on release if 
it's using LSP4E snapshots or milestones.
___
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] LSP4E participation in Photon

[Doug Schaefer]

Just curious, why +3? We are thinking of adding a component that uses it to CDT 
to access the clangd language server.

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mickael 
Istria
Sent: Thursday, August 10, 2017 5:05 AM
To: Cross project issues 
Subject: [cross-project-issues-dev] LSP4E participation in Photon

LSP4E will participate in photon with an offset of +3: 
https://projects.eclipse.org/projects/technology.lsp4e/releases/1.0.0

--
Mickael Istria
Eclipse IDE developer, at 
Red Hat Developers community
___
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] CDT in Photon

[Doug Schaefer]

CDT will be participating in Photon with release 9.5 (9.4 is in Oxygen.2). We 
probably maintain our cyclical build with other projects that we use and that 
use us starting at +1 unless I can suck them all into CDT which I have an open 
action on. It's complicated...

Doug.
___
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] Oxygen RC4 respin complete

[Doug Schaefer]

Oh, that, no I prematurely renamed the RC4 dir as the release and forgot
to update simrel. BTW, if anyone sees verify errors, please rebase to pick
that up.

Thanks,
Doug.

On 2017-06-20, 2:27 PM, "cross-project-issues-dev-boun...@eclipse.org on
behalf of Frederic Gurr" <cross-project-issues-dev-boun...@eclipse.org on
behalf of frederic.g...@eclipse-foundation.org> wrote:

>Sorry. I misinterpreted your commit message then.
>
>On 20.06.2017 19:39, Doug Schaefer wrote:
>> Actually, it doesn¹t include the Launch Bar fix. I am preparing a
>>service
>> release for it and the CDT that will ship on day 0 via the CDT p2 site.
>> 
>> On 2017-06-20, 1:35 PM, "cross-project-issues-dev-boun...@eclipse.org on
>> behalf of Frederic Gurr" <cross-project-issues-dev-boun...@eclipse.org
>>on
>> behalf of frederic.g...@eclipse-foundation.org> wrote:
>> 
>>> Hi,
>>>
>>> The Oxygen RC4 respin has been completed. It includes the Launch Bar
>>> fix, the MPC fix and the TCF piggy-back.
>>>
>>> EPP packages are still building.
>>>
>>> Please note:
>>> We are currently in quiet week until June 27th. There will be no
>>>further
>>> builds. That time is reserved for final, in depth testing, and
>>> preparation for release. Emergency rebuilds might be considered, by
>>> following the usual Planning Council Exception Process, but only for
>>> serious, blocking regressions that have a "cross-project" impact.
>>>
>>> Regards,
>>>
>>> Fred
>>>
>>> -- 
>>> Frederic Gurr
>>>
>>> Release Engineer
>>> 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
>> 
>> ___
>> 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] Oxygen RC4 respin complete

[Doug Schaefer]

Actually, it doesn¹t include the Launch Bar fix. I am preparing a service
release for it and the CDT that will ship on day 0 via the CDT p2 site.

On 2017-06-20, 1:35 PM, "cross-project-issues-dev-boun...@eclipse.org on
behalf of Frederic Gurr"  wrote:

>Hi,
>
>The Oxygen RC4 respin has been completed. It includes the Launch Bar
>fix, the MPC fix and the TCF piggy-back.
>
>EPP packages are still building.
>
>Please note:
>We are currently in quiet week until June 27th. There will be no further
>builds. That time is reserved for final, in depth testing, and
>preparation for release. Emergency rebuilds might be considered, by
>following the usual Planning Council Exception Process, but only for
>serious, blocking regressions that have a "cross-project" impact.
>
>Regards,
>
>Fred
>
>-- 
>Frederic Gurr
>
>Release Engineer
>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

___
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] Oxygen RC4 staging repository is complete

[Doug Schaefer]

From: 
<cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>>
 on behalf of Mickael Istria <mist...@redhat.com<mailto:mist...@redhat.com>>
Reply-To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Date: Thursday, June 15, 2017 at 1:25 PM
To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Subject: Re: [cross-project-issues-dev] Oxygen RC4 staging repository is 
complete

On Thu, Jun 15, 2017 at 5:00 PM, Doug Schaefer 
<dschae...@blackberry.com<mailto:dschae...@blackberry.com>> wrote:
We¹ve found a deadlock in the Launch Bar on startup. Would that warrant a
respin? Not that many people use it and I can do a maintenance release to
pick up the fix before we go live. Thoughts?

Is the LaunchBar enabled by default in any EPP package?

Nope. It’s used by the Arduino C++ community but they install that from the 
Marketplace and I can point to the maintenance release from there.

And it is a pretty small window that I’m not sure how often it’ll get hit. 
We’ve only seen it on CI machines and even then only on our Macs (this is our 
internal QNX machines), though it was consistently hit on every run (we launch 
60 times each run).

And of course, when it does get hit, Eclipse hangs on startup and it’s hard to 
know why unless you run jstack against it. Not a great user experience.

I’m just checking if anyone feels we should fix it in simrel. The communities I 
am charged with caring about don’t necessary rely on it.

Doug.
___
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] Oxygen RC4 staging repository is complete

[Doug Schaefer]

We¹ve found a deadlock in the Launch Bar on startup. Would that warrant a
respin? Not that many people use it and I can do a maintenance release to
pick up the fix before we go live. Thoughts?

On 2017-06-15, 8:45 AM, "cross-project-issues-dev-boun...@eclipse.org on
behalf of Denis Roy"  wrote:

>Thanks, Fred!
>
>Denis
>
>
>On 06/14/2017 09:50 PM, Frederic Gurr wrote:
>> Hi,
>>
>> The staging repository for Oxygen RC4 is complete.
>> => http://download.eclipse.org/staging/oxygen/
>>
>> SimRel aggregation builds are disabled until Friday after the release at
>> 10am EDT.
>>
>> Thanks for all contributions.
>>
>> Regards,
>>
>> Fred
>>
>>
>
>___
>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] simrel validate fails with error 13

[Doug Schaefer]

Looks like EGerrit has gone missing.

Sent from my BlackBerry - the most secure mobile device - via the Rogers Network
From: g.wat...@computer.org
Sent: June 6, 2017 9:24 AM
To: cross-project-issues-dev@eclipse.org
Reply-to: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] simrel validate fails with error 13


Anyone know how to fix this?

Thanks,
Greg


09:18:01  runAggregatorValidateOnly:
09:18:01   [echo] AGG_APP_ARGS: --production --buildModel 
/home/hudson/genie.simrel/.hudson/jobs/simrel.oxygen.runaggregator.VALIDATE.gerrit/workspace/org.eclipse.simrel.build/simrel.aggr
 --buildRoot 
/home/hudson/genie.simrel/.hudson/jobs/simrel.oxygen.runaggregator.VALIDATE.gerrit/workspace/aggregation
 --agentLocation 
/home/hudson/genie.simrel/.hudson/jobs/simrel.oxygen.runaggregator.VALIDATE.gerrit/workspace/.p2AgentLocation
 --eclipseLogLevel DEBUG --logLevel DEBUG --emailFrom 
david_willi...@eclipse.org --emailFromName 
oxygenAggregator --logURL 
https://hudson.eclipse.org/simrel/job/simrel.oxygen.runaggregator.VALIDATE.gerrit/635/console
 --subjectPrefix oxygenAggregation --action VALIDATE
09:18:01   [exec] Install location:
09:18:01   [exec] 
file:/jobs/genie.simrel/simrel.oxygen.runaggregator.VALIDATE.gerrit/workspace/eclipseInstall/eclipse/
09:18:01   [exec] Configuration file:
09:18:02   [exec] 
file:/jobs/genie.simrel/simrel.oxygen.runaggregator.VALIDATE.gerrit/workspace/eclipseInstall/eclipse/configuration/config.ini
 loaded
09:18:02   [exec] Configuration location:
09:18:02   [exec] 
file:/jobs/genie.simrel/simrel.oxygen.runaggregator.VALIDATE.gerrit/workspace/eclipseInstall/eclipse/configuration/
09:18:02   [exec] Framework located:
09:18:02   [exec] 
file:/jobs/genie.simrel/simrel.oxygen.runaggregator.VALIDATE.gerrit/workspace/eclipseInstall/eclipse/plugins/org.eclipse.osgi_3.11.2.v20161107-1947.jar
09:18:02   [exec] Loading extension: 
reference:file:org.eclipse.osgi.compatibility.state_1.0.200.v20160504-1419.jar
09:18:02   [exec]   eclipse.properties not found
09:18:02   [exec] Framework classpath:
09:18:02   [exec] 
file:/jobs/genie.simrel/simrel.oxygen.runaggregator.VALIDATE.gerrit/workspace/eclipseInstall/eclipse/plugins/org.eclipse.osgi_3.11.2.v20161107-1947.jar
09:18:02   [exec] 
file:/jobs/genie.simrel/simrel.oxygen.runaggregator.VALIDATE.gerrit/workspace/eclipseInstall/eclipse/plugins/
09:18:02   [exec] 
file:/jobs/genie.simrel/simrel.oxygen.runaggregator.VALIDATE.gerrit/workspace/eclipseInstall/eclipse/plugins/org.eclipse.osgi.compatibility.state_1.0.200.v20160504-1419.jar
09:18:02   [exec] Debug options:
09:18:02   [exec] 
file:/jobs/genie.simrel/simrel.oxygen.runaggregator.VALIDATE.gerrit/workspace/org.eclipse.simrel.tools/.options
 not found
09:18:03   [exec] Time to load bundles: 10
09:18:03   [exec] Starting application: 1632
09:18:04   [exec] Configuration:
09:18:04   [exec] com.google.guava / 15.0.0.v201403281430
09:18:04   [exec] com.ibm.icu / 56.1.0.v201601250100
09:18:04   [exec] com.jcraft.jsch / 0.1.53.v201508180515
09:18:04   [exec] com.sun.el / 2.2.0.v201303151357
09:18:04   [exec] javax.annotation / 1.2.0.v201602091430
09:18:04   [exec] javax.el / 2.2.0.v201303151357
09:18:04   [exec] javax.inject / 1.0.0.v20091030
09:18:04   [exec] javax.servlet / 3.1.0.v201410161800
09:18:04   [exec] javax.servlet.jsp / 2.2.0.v201112011158
09:18:04   [exec] javax.xml / 1.3.4.v201005080400
09:18:04   [exec] org.apache.ant / 1.9.6.v201510161327
09:18:04   [exec] org.apache.batik.css / 1.7.0.v201011041433
09:18:04   [exec] org.apache.batik.util / 1.7.0.v201011041433
09:18:04   [exec] org.apache.batik.util.gui / 1.7.0.v200903091627
09:18:04   [exec] org.apache.commons.codec / 1.6.0.v201305230611
09:18:04   [exec] org.apache.commons.jxpath / 1.3.0.v200911051830
09:18:04   [exec] org.apache.commons.logging / 1.1.1.v201101211721
09:18:04   [exec] org.apache.felix.gogo.command / 0.10.0.v201209301215
09:18:04   [exec] org.apache.felix.gogo.runtime / 0.10.0.v201209301036
09:18:04   [exec] org.apache.felix.gogo.shell / 0.10.0.v201212101605
09:18:04   [exec] org.apache.httpcomponents.httpclient / 4.3.6.v201511171540
09:18:04   [exec] org.apache.httpcomponents.httpcore / 4.3.3.v201411290715
09:18:04   [exec] org.apache.jasper.glassfish / 2.2.2.v201501141630
09:18:04   [exec] org.apache.lucene.analysis / 3.5.0.v20120725-1805
09:18:04   [exec] org.apache.lucene.core / 3.5.0.v20120725-1805
09:18:04   [exec] org.eclipse.ant.core / 3.4.100.v20160505-0642
09:18:04   [exec] org.eclipse.cbi.p2repo.aggregator / 1.0.100.20161208-2243
09:18:04   [exec] org.eclipse.cbi.p2repo.aggregator.engine / 
1.0.100.20161203-2118
09:18:04   [exec] org.eclipse.cbi.p2repo.aggregator.engine.maven / 
1.0.100.20161208-2243
09:18:04   [exec] 

Re: [cross-project-issues-dev] gdk_test_simulate_button

[Doug Schaefer]

Thanks Alex.

BTW, I was running megacity but without any parameters. Worked on one of
my CI machines but not the other (almost exact duplicate). Adding
‹sm-disable ‹replace seems to have helped. Not sure why.

Cheers,
Doug

On 2017-05-26, 3:18 AM, "cross-project-issues-dev-boun...@eclipse.org on
behalf of Aleksandar Kurtakov"
<cross-project-issues-dev-boun...@eclipse.org on behalf of
akurt...@redhat.com> wrote:

>If the bug has been against SWT, I would have seen it way earlier :) .
>Opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=517273 with
>proposed fix for RC3 .
>
>Regards,
>Alex
>
>On Fri, May 26, 2017 at 1:40 AM, Doug Schaefer <dschae...@blackberry.com>
>wrote:
>> And, yes, there is a bug open on this from Carsten.
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=511551
>>
>> From: <cross-project-issues-dev-boun...@eclipse.org> on behalf of Doug
>> Schaefer <dschae...@blackberry.com>
>> Reply-To: Cross project issues <cross-project-issues-dev@eclipse.org>
>> Date: Thursday, May 25, 2017 at 6:36 PM
>> To: Cross project issues <cross-project-issues-dev@eclipse.org>
>> Subject: [cross-project-issues-dev] gdk_test_simulate_button
>>
>> Hey gang,
>>
>> I¹m getting crashes on certain machines when running tests against
>>Oxygen.
>> This has been reported before, and it seems to have some relation to
>>the GTK
>> webkit library. Do we have documented somewhere how to properly set up a
>> Linux machine to run Oxygen, or at least run tests so they don¹t crash?
>>
>> Thanks!
>> Doug
>>
>> For reference, the crash:
>>
>> 18:18:58 #
>> 18:18:58 # A fatal error has been detected by the Java Runtime
>>Environment:
>> 18:18:58 #
>> 18:18:58 #  SIGSEGV (0xb) at pc=0x7f48ad594a40, pid=19297,
>> tid=0x7f48d0e6f700
>> 18:18:58 #
>> 18:18:58 # JRE version: Java(TM) SE Runtime Environment (8.0_111-b14)
>>(build
>> 1.8.0_111-b14)
>> 18:18:58 # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.111-b14 mixed
>>mode
>> linux-amd64 compressed oops)
>> 18:18:58 # Problematic frame:
>> 18:18:58 # C  [libgdk-3.so.0+0x45a40]  gdk_test_simulate_button+0x0
>> 18:18:58 #
>>
>>
>>
>> ___
>> 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
>
>
>
>-- 
>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] gdk_test_simulate_button

[Doug Schaefer]

And, yes, there is a bug open on this from Carsten. 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=511551

From: 
<cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>>
 on behalf of Doug Schaefer 
<dschae...@blackberry.com<mailto:dschae...@blackberry.com>>
Reply-To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Date: Thursday, May 25, 2017 at 6:36 PM
To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Subject: [cross-project-issues-dev] gdk_test_simulate_button

Hey gang,

I’m getting crashes on certain machines when running tests against Oxygen. This 
has been reported before, and it seems to have some relation to the GTK webkit 
library. Do we have documented somewhere how to properly set up a Linux machine 
to run Oxygen, or at least run tests so they don’t crash?

Thanks!
Doug

For reference, the crash:


18:18:58 #
18:18:58 # A fatal error has been detected by the Java Runtime Environment:
18:18:58 #
18:18:58 #  SIGSEGV (0xb) at pc=0x7f48ad594a40, pid=19297, 
tid=0x7f48d0e6f700
18:18:58 #
18:18:58 # JRE version: Java(TM) SE Runtime Environment (8.0_111-b14) (build 
1.8.0_111-b14)
18:18:58 # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.111-b14 mixed mode 
linux-amd64 compressed oops)
18:18:58 # Problematic frame:
18:18:58 # C  [libgdk-3.so.0+0x45a40]  gdk_test_simulate_button+0x0
18:18:58 #


___
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] gdk_test_simulate_button

[Doug Schaefer]

Hey gang,

I’m getting crashes on certain machines when running tests against Oxygen. This 
has been reported before, and it seems to have some relation to the GTK webkit 
library. Do we have documented somewhere how to properly set up a Linux machine 
to run Oxygen, or at least run tests so they don’t crash?

Thanks!
Doug

For reference, the crash:


18:18:58 #
18:18:58 # A fatal error has been detected by the Java Runtime Environment:
18:18:58 #
18:18:58 #  SIGSEGV (0xb) at pc=0x7f48ad594a40, pid=19297, 
tid=0x7f48d0e6f700
18:18:58 #
18:18:58 # JRE version: Java(TM) SE Runtime Environment (8.0_111-b14) (build 
1.8.0_111-b14)
18:18:58 # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.111-b14 mixed mode 
linux-amd64 compressed oops)
18:18:58 # Problematic frame:
18:18:58 # C  [libgdk-3.so.0+0x45a40]  gdk_test_simulate_button+0x0
18:18:58 #


___
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] Are restrictions on Bugzilla worse thanspam?

[Doug Schaefer]

From: 
>
 on behalf of Denis Roy >
Reply-To: Cross project issues 
>
Date: Monday, November 14, 2016 at 11:22 AM
To: 
"cross-project-issues-dev@eclipse.org"
 
>
Subject: Re: [cross-project-issues-dev] Are restrictions on Bugzilla worse 
thanspam?

+1

We're using re-captcha on the sign-up page, but since Bugzilla doesn't have a 
moderation system it makes it an easy target. Since Bugzilla doesn't have a 
clean bug deletion process either it makes a messy cleanup.

Question that comes to mind, what criteria does the moderation system have at 
rejecting sign-ups? How do you know the person is about to post spam versus 
raise a real bug?



Wiki and Forums have a crowd-sourced First Post moderation system which is 
quite effective and unintrusive. I've attempted to contact the Bugzilla 
developers to throw resources at the issue but I'm getting little traction.

With all due respect (and you know I do :) ), I have counter examples on how 
effective it is, at least lately, where a CDT committer still had to wait too 
long to get his Wiki access granted as we were putting things together for the 
Neon.2 release.

I have no good answers but this really is a no win for anyone.



Denis


On 13/11/16 10:28 AM, Daniel Megert wrote:
> Wasn't there is a captcha mechanism in place which prevents robots from 
> registering accounts?

The webmaster said that the spam was not created by robots but real humans.

Dani



From:Gunnar Wagenknecht 

To:Cross project issues 

Date:12.11.2016 19:03
Subject:Re: [cross-project-issues-dev] Are restrictions on Bugzilla 
worse thanspam?
Sent by:
cross-project-issues-dev-boun...@eclipse.org




I agree with Mickael that the situation is not good for an open community. 
Manual moderation does not scale and it is an extra wall for contributing.

Wasn't there is a captcha mechanism in place which prevents robots from 
registering accounts? Can we please prioritize the work to get the account 
sign-up fixed so that only humans can sign up?

-Gunnar

--
Gunnar Wagenknecht
gun...@wagenknecht.org, http://guw.io/






On 12 Nov 2016, at 17:49, Daniel Megert 
> wrote:

The spam wasted at least half an hour of my time every day, so "NO", the spam 
must not come back. NO WAY!

If you feel good about the spam I suggest you sign up as moderator for the new 
accounts.

Dani



From:Mickael Istria >
To:Cross project issues 
>
Date:12.11.2016 17:07
Subject:[cross-project-issues-dev] Are restrictions on Bugzilla worse 
thanspam?
Sent by:
cross-project-issues-dev-boun...@eclipse.org




TL;DR: Bugzilla restrictions block new contributors - that's worse than spam.

Hi all,

A few weeks ago, because of a spam attack, access to bugzilla and ability to 
report bugs and comment on bugs for new members was restricted. New members now 
have to ask webmasters to be whilelisted and allowed to interact with the 
community.

I've got some colleague who just registered and tried to contribute and totally 
failed at it. The message about asking webmasters for whilelist wasn't visible 
enough apparently so they didn't realize it was necessary and just ended up  
with an account which seem unusable to them. So I had to forward messages in 
their name: https://bugs.eclipse.org/bugs/show_bug.cgi?id=506244#c19
Moreover, in that case, we're speaking about someone working on week-ends and 
is ready to contribute on week-ends, and I don't expect webmasters to promptly 
react to whilelisting request on week-ends. So even if the user would have sent 
a mail, it could have requested days to be processed.
If I had not been there to assist my colleague in contributing, he'd just had 
given up. And I'm pretty sure that several other people have given up 
contributing since the introduction of this "ask for permission" rule.

So IMO, the current state is by far worse than having spam. It makes the 
community more difficult to join for new subscribers and appear more closed 
than it is. A lot of effort were done in the past to "reduce barriers" from 
users to contributors, 

Re: [cross-project-issues-dev] Upgrading HIPPs to SLES12

[Doug Schaefer]

Cool. I can see that being very useful for setting up test environments,
e.g. With different versions of gdb for CDT with different distros of
Linux. Being SLES has somewhat handcuffed us in the past since our
committers aren¹t very familiar with it.

Thanks!
Doug.

On 2016-09-08, 11:25 AM, "cross-project-issues-dev-boun...@eclipse.org on
behalf of Frederic Gurr" <cross-project-issues-dev-boun...@eclipse.org on
behalf of frederic.g...@eclipse.org> wrote:

>Hi,
>
>Technically yes, but the Docker packages are not installed yet.
>
>Regards,
>
>Fred
>
>On 07.09.2016 19:40, Doug Schaefer wrote:
>> Does SLES12 give us the ability to use Docker containers for our build
>> jobs?
>> 
>> Thanks!
>> Doug.
>> 
>> On 2016-09-07, 1:35 PM, "cross-project-issues-dev-boun...@eclipse.org on
>> behalf of Frederic Gurr" <cross-project-issues-dev-boun...@eclipse.org
>>on
>> behalf of frederic.g...@eclipse.org> wrote:
>> 
>>> Hi,
>>>
>>> The following HIPPs will be upgraded to SLES12:
>>>
>>> * bpmn2
>>> * ebr
>>> * equinox
>>> * etrice
>>> * ptp
>>> * rmf
>>> * sirius
>>> * thym
>>> * umlgen
>>> * uomo
>>> * vex
>>>
>>> The upgrade is scheduled for Friday, September 9th, 10am EDT.
>>>
>>> Downtime will be a few hours.
>>>
>>>
>>> Please let me know if you have any concerns.
>>>
>>> Regards,
>>>
>>> Fred
>>> ___
>>> 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

___
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] Upgrading HIPPs to SLES12

[Doug Schaefer]

Does SLES12 give us the ability to use Docker containers for our build
jobs?

Thanks!
Doug.

On 2016-09-07, 1:35 PM, "cross-project-issues-dev-boun...@eclipse.org on
behalf of Frederic Gurr"  wrote:

>Hi,
>
>The following HIPPs will be upgraded to SLES12:
>
>* bpmn2
>* ebr
>* equinox
>* etrice
>* ptp
>* rmf
>* sirius
>* thym
>* umlgen
>* uomo
>* vex
>
>The upgrade is scheduled for Friday, September 9th, 10am EDT.
>
>Downtime will be a few hours.
>
>
>Please let me know if you have any concerns.
>
>Regards,
>
>Fred
>___
>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] Gerrit is failing to connect to https://hudson.eclipse.org

[Doug Schaefer]

Same here from build.eclipse.org. I use wget and am getting “No route to host” 
to hudson.

From: 
>
 on behalf of Sravan K Lakkimsetti 
>
Reply-To: Cross project issues 
>
Date: Wednesday, August 31, 2016 at 12:08 PM
To: Cross project issues 
>
Subject: Re: [cross-project-issues-dev] Gerrit is failing to connect to 
https://hudson.eclipse.org


I am still having connection issues. I use curl to connect to 
hudson.eclipse.org. but I am getting the following error
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
Dload  Upload   Total   SpentLeft  Speed

  0 00 00 0  0  0 --:--:--  0:00:58 --:--:-- 0
 0 00 00 0  0  0 --:--:--  0:00:59 --:--:-- 0
 0 00 00 0  0  0 --:--:--  0:01:00 --:--:-- 0
 0 00 00 0  0  0 --:--:--  0:01:00 --:--:-- 0
curl: (56) Received HTTP code 503 from proxy after CONNECT


Thanks and Regards,
Sravan

Sravan Kumar Lakkimsetti
IBM India Pvt Ltd,
Embassy Golf Links Business Park, D Block,
Off Indiranagar-Kormangla Inner Ring Road,
Bangalore - 560071, India
Phone: 91-80-41776858

[Inactive hide details for "Webmaster(Matt Ward)" ---31-08-2016 07:58:10 
PM---Sorry folks this was the result of a missing dns u]"Webmaster(Matt Ward)" 
---31-08-2016 07:58:10 PM---Sorry folks this was the result of a missing dns 
update . I've fixed that so things should now be b

From: "Webmaster(Matt Ward)" 
>
To: Cross project issues 
>
Date: 31-08-16 07:58 PM
Subject: Re: [cross-project-issues-dev] Gerrit is failing to connect to 
https://hudson.eclipse.org
Sent by: 
cross-project-issues-dev-boun...@eclipse.org





Sorry folks this was the result of a missing dns update .  I've fixed
that so things should now be back to normal.

-Matt.

On 08/30/2016 08:28 PM, Jeff Johnston wrote:
> I hit the restart button on the account page and it appeared to bring down
> the hipp instance as I had to wait a bit for it to come up.  I will try your
> suggestion, but for the time-being I have cheated and put the launchbar stuff
> in the Linux Tools download area as a temporary work-around.
>
> -- Jeff J.
>
> - Original Message -
>> On 08/30/2016 05:32 PM, Jeff Johnston wrote:
>>
>>
>> I tried restarting our hipp instance and now linuxtools hudson pages are
>> unavailable (503). This is bad
>> timing since we are trying to get RC2 out for tomorrow.
>> While I don't know if "restarting" will fix the issue, just thought I would
>> mention that I have not seen "restart" work for a very long time.
>> (Even though it "acts like" it does on the account page.)
>>
>> But what does work, for me, is to "stop" the server. And, then "start" it.
>> [Not sure if you meant "restart" literally or not or if this is common
>> knowledge.]
>>
>> HTH
>>
>> ___
>> 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




-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or 

Re: [cross-project-issues-dev] Gerrit is failing to connect to https://hudson.eclipse.org

[Doug Schaefer]

Marketplace went down too. This a bigger than Gerrit.

Sent from my BlackBerry - the most secure mobile device - via the Rogers Network
From:marc-andre.lape...@ericsson.com
Sent:August 30, 2016 5:42 PM
To:cross-project-issues-dev@eclipse.org
Reply-to:cross-project-issues-dev@eclipse.org
Cc:e...@eclipse.org
Subject:Re: [cross-project-issues-dev] Gerrit is failing to connect to 
https://hudson.eclipse.org


I'm seeing something that sounds similar on the CDT HIPP

17:33:18  Aug 30, 2016 5:33:18 PM 
org.apache.http.impl.client.DefaultRequestDirector tryConnect
17:33:18  INFO: I/O exception (java.net.NoRouteToHostException) caught when 
connecting to {s}->https://hudson.eclipse.org: No route to host
17:33:18  Aug 30, 2016 5:33:18 PM 
org.apache.http.impl.client.DefaultRequestDirector tryConnect
17:33:18  INFO: Retrying connect to {s}->https://hudson.eclipse.org
...

https://hudson.eclipse.org/cdt/job/cdt-verify/5961/console

Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Jeff Johnston 
[jjohn...@redhat.com]
Sent: Tuesday, 30 August 2016 5:32 PM
To: Cross project issues
Cc: Wayne Beaton
Subject: Re: [cross-project-issues-dev] Gerrit is failing to connectto  
https://hudson.eclipse.org

I tried restarting our hipp instance and now linuxtools hudson pages are 
unavailable (503).  This is bad
timing since we are trying to get RC2 out for tomorrow.

- Original Message -
> I am having trouble with the Linux Tools gerrit jobs.  We get the launchbar
> stuff from
> the hudson launchbar-master job last successful build.
>
> I keep getting no route to host when our target file tries to connect to the
> repo.
>
> Any ideas?
>
> -- Jeff J.
> ___
> 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
___
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] Graphiti participating in Oxygen

[Doug Schaefer]

The +# days thing has never made sense, really. If you really chain 
dependencies I’m sure you’d get into double digits. In fact, CDT cycles on 
itself with a couple of other projects.

Probably what would be better would be a better way to publicize API changes 
that affect downstream builds. Don’t really have an answer there but it is what 
causes problems. If APIs are well managed, in theory, you can build before 
you’re dependencies do.

Just a thought,
Doug.

From: 
>
 on behalf of "Wenz, Michael" 
>
Reply-To: Cross project issues 
>
Date: Monday, July 18, 2016 at 11:22 AM
To: Cross project issues 
>
Subject: Re: [cross-project-issues-dev] Graphiti participating in Oxygen

David,

yes, you are right Graphiti is a framework. On the other hand we have 
dependencies to GEF and EMF Transactions/Validation with is at +2.

Graphiti has been on +3 since it joined the release train, so far it has never 
been an issue. Or at least these issues did not reach me.

In case any user of Graphiti struggles with this, this would be a good time to 
speak up. I’m open towards changing to an earlier day in case that is required.

Thanks,
Michael

From: 
cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Montag, 18. Juli 2016 16:25
To: Cross project issues 
>
Subject: Re: [cross-project-issues-dev] Graphiti participating in Oxygen

I believe Graphiti is a "framework", right? To be used by others? As such +3 
does not make much sense. +3 is more for "leaf" components that no one else 
depends on. +1 or +2 makes more sense to me, depending on what you depend on.

As always, feel free to correct any misconceptions I have.





From:"Wenz, Michael" >
To:Cross project issues 
>,
Date:07/18/2016 02:23 AM
Subject:[cross-project-issues-dev] Graphiti participating in Oxygen
Sent by:
cross-project-issues-dev-boun...@eclipse.org




Hi,

Graphiti will be participating in Oxygen:
https://projects.eclipse.org/projects/modeling.graphiti/releases/0.14.0

Offset will be +3.

Michael___
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] org.eclipse.userstorage?

[Doug Schaefer]

Ah, never mind. It¹s just easier to grab stuff from simrel, just like a
user would.

On 2016-07-07, 2:30 PM, "cross-project-issues-dev-boun...@eclipse.org on
behalf of Carsten Reckord" <cross-project-issues-dev-boun...@eclipse.org
on behalf of reck...@yatta.de> wrote:

>Hi Doug,
>
>the USS plugins come from
>http://download.eclipse.org/oomph/uss/updates/latest.
>
>See 
>http://git.eclipse.org/c/mpc/org.eclipse.epp.mpc.git/plain/org.eclipse.epp
>.mpc-target/staging.target for details.
>
>Best,
>Carsten
>
>On July 7, 2016 8:17:02 PM CEST, Doug Schaefer <dschae...@blackberry.com>
>wrote:
>>Hey gang,
>>
>>I¹m cleaning up my commercial product build so that it doesn¹t build
>>off of the simrel repo. I can¹t seem to find what project repo
>>contributes the org.eclipse.userstorage plug-in that the MarketPlace
>>core plug-in depends on. Any ideas?
>>
>>Thanks,
>>Doug.
>>
>>
>>
>>
>>___
>>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
>
>-- 
>Sent from my Android phone. Please excuse my brevity.
>--
>Yatta Solutions GmbH
>- Carsten Reckord -
>
>t +49 (0)69 2475666-33
>f +49 (0)69 2475668-0
>e reck...@yatta.de
>
>Anschrift Office Kassel
>Universitätsplatz 12
>34127 Kassel
>
>Anschrift Office Frankfurt a.M.
>Mainzer Landstraße 50
>60325 Frankfurt a.M.
>
>Sitz, Handelsregister:
>Sitz der Gesellschaft: Kassel
>Amtsgericht Kassel, HRB 14720
>USt-IdNr DE263191529
>
>Geschäftsführung:
>Johannes Jacop
>Dr. Christian Schneider
>
>Kontakt Geschäftsstelle:
>t +49 (0)69 2475666-0
>f +49 (0)69 2475668-0
>e i...@yatta.de
>
>___
>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] org.eclipse.userstorage?

[Doug Schaefer]

Thanks Carsten, I had just found that file a minute ago :). What I can¹t
see though is how the uss site gets into the simrel. I can¹t seem to find
it mentioned in the b3 aggregation files. Or is it a composite under the
rest of oomph?

Doug.

On 2016-07-07, 2:30 PM, "cross-project-issues-dev-boun...@eclipse.org on
behalf of Carsten Reckord" <cross-project-issues-dev-boun...@eclipse.org
on behalf of reck...@yatta.de> wrote:

>Hi Doug,
>
>the USS plugins come from
>http://download.eclipse.org/oomph/uss/updates/latest.
>
>See 
>http://git.eclipse.org/c/mpc/org.eclipse.epp.mpc.git/plain/org.eclipse.epp
>.mpc-target/staging.target for details.
>
>Best,
>Carsten
>
>On July 7, 2016 8:17:02 PM CEST, Doug Schaefer <dschae...@blackberry.com>
>wrote:
>>Hey gang,
>>
>>I¹m cleaning up my commercial product build so that it doesn¹t build
>>off of the simrel repo. I can¹t seem to find what project repo
>>contributes the org.eclipse.userstorage plug-in that the MarketPlace
>>core plug-in depends on. Any ideas?
>>
>>Thanks,
>>Doug.
>>
>>
>>
>>
>>___
>>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
>
>-- 
>Sent from my Android phone. Please excuse my brevity.
>--
>Yatta Solutions GmbH
>- Carsten Reckord -
>
>t +49 (0)69 2475666-33
>f +49 (0)69 2475668-0
>e reck...@yatta.de
>
>Anschrift Office Kassel
>Universitätsplatz 12
>34127 Kassel
>
>Anschrift Office Frankfurt a.M.
>Mainzer Landstraße 50
>60325 Frankfurt a.M.
>
>Sitz, Handelsregister:
>Sitz der Gesellschaft: Kassel
>Amtsgericht Kassel, HRB 14720
>USt-IdNr DE263191529
>
>Geschäftsführung:
>Johannes Jacop
>Dr. Christian Schneider
>
>Kontakt Geschäftsstelle:
>t +49 (0)69 2475666-0
>f +49 (0)69 2475668-0
>e i...@yatta.de
>
>___
>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] org.eclipse.userstorage?

[Doug Schaefer]

Hey gang,

I’m cleaning up my commercial product build so that it doesn’t build off of the 
simrel repo. I can’t seem to find what project repo contributes the 
org.eclipse.userstorage plug-in that the MarketPlace core plug-in depends on. 
Any ideas?

Thanks,
Doug.
___
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] CodeEnvy continues to use deceptive wording that's harmful to Eclipse

[Doug Schaefer]

Great words Max. Whole heartedly agree.

I think the real issue started at EclipseCon where they presented themselves as 
“the next generation Eclipse IDE”, not “a next generation Eclipse IDE", or as I 
see now their web pages simply stating "Eclipse Che Next Generation Eclipse 
IDE” which implies “the” if you read it that way. Funny how that one word has 
triggered such an emotional response.

At any rate, as we keep hearing from Steve O’Grady’s “The New Kingmakers” book, 
developers will decide, not marketing people as much as they try. Che does have 
value as a cloud-based IDE for those who want to use such things. I don’t think 
that impacts much the need for our veteran Eclipse IDE much.

As I’ve stated many times, I’m more worried about developers dropping their 
IDEs for fast editors-come-IDEs like Sublime and VS Code. We have enough to 
work on to compete there.

Doug.


From: 
>
 on behalf of Max Andersen >
Reply-To: Cross project issues 
>
Date: Thursday, June 30, 2016 at 3:36 AM
To: Cross project issues 
>
Subject: Re: [cross-project-issues-dev] CodeEnvy continues to use deceptive 
wording that's harmful to Eclipse

Hi Konstantin,

Below is my opinon as an Eclipse community member (not speaking on behalf of 
the foundation nor my employer)

I recognize the wording CodeEnvy or rather the Eclipse Che project is bold and 
for some maybe even directly threatining - but I do not believe the foundation 
as such should restrict a specific projects ability to market it self as long 
as it is not directly deceiving nor outright lying.

And Che stating it is a next generation Eclipse IDE is not false, neither was 
it when the similar wording was used by the press when Eclipse Orion was 
starting off.

If we (the desktop Eclipse IDE community) want desktop Eclipse IDE to survive 
and grow we should not be scared about words stated by other communities inside 
or outside Eclipse.

We should be encouraged to show show the desktop Eclipse IDE also can grow and 
not stay stagnated as it have done for a while now.

This really is nothing new and sure we can "blame" IBM and other companies for 
retracting its original people investement into desktop Eclipse IDE - but that 
are those companies choice, not the Foundation. We'll either need to replace 
those people or change how we do things. I've helped where I can from my role 
in Red Hat but just like IBM couldn't pull it of forever alone, neither can Red 
Hat.

This is why I've done what I can and will continue to do in future on the 
desktop Eclipse platform features, and I encourage everyone to do what you can 
too. Talk to your companies, talk to your contributors and encourage 
collaboration and more contributions to grow the desktop Eclipse IDE.

And in that, we cannot ignore there are other markets where a cloud IDE like 
Eclipse Che has its major advantages over desktop Eclipse - just like desktop 
Eclipse IDE has advantages over cloud IDE's.

We are entering a world where there no longer will be a "single" IDE, the 
community both inside and outside Eclipse foundation have spoken stating that 
one IDE does not fit all. Some don't even want a full IDE, just a fancy editor.

As a long time contributor to desktop Eclipse IDE and other tools out there, I 
understand that there are limited number of people who will actually be able to 
contribute to a single platform. Thus the "multi-IDE" world do scare me, mainly 
since it means more work for me and my team ;/

Backing the language service protocol is my way to try and build the technical 
bridges between these multiple IDE's - if it works, all will grow. If not, one 
will grow stronger faster and win.

This is how opensource works. This is how (almost) anything works and evolves.

I encourage you and everyone else to help grow the world of Eclipse IDE's to be 
a player in the  world of next gen IDE's - it is together we win. No individual 
person or single company will carry this.

Thank you,
/max



On Wed, Jun 29, 2016 at 6:11 PM, Konstantin Komissarchik 
> 
wrote:
I was just reading the latest Microsoft/RedHat/Codenvy press release and came 
across the problematic wording that we’ve seen before.

Microsoft Visual Studio Code and Eclipse Che, the next-generation Eclipse IDE, 
have added support for the protocol.

https://www.redhat.com/en/about/press-releases/red-hat-codenvy-and-microsoft-collaborate-language-server-protocol

I think it’s great that Eclipse Foundation is getting more technologically 
diverse, but I find it very concerning that Eclipse Foundation is allowing 
Codenvy/Che to continue to use wording like 

Re: [cross-project-issues-dev] CodeEnvy continues to use deceptive wording that's harmful to Eclipse

[Doug Schaefer]

I guess one question, is that really the Foundation’s role? Is it not up to us, 
the community, to make sure the messaging is clear?

Though I’m not as worried about that at the moment. I gave a short talk to a 
local Ottawa IoT meetup and used the term “Eclipse” and they knew exactly what 
I was talking about, using Eclipse to program their Arduinos. And they rather 
liked the idea :).

Aside from that, the language server protocol is a great initiative and 
something our tooling really needs. Don’t forget Red Hat is also a major player 
here and I think we’ll all benefit from it.

Doug.

From: 
>
 on behalf of Konstantin Komissarchik 
>
Reply-To: Cross project issues 
>
Date: Wednesday, June 29, 2016 at 12:11 PM
To: 
"cross-project-issues-dev@eclipse.org"
 
>
Subject: [cross-project-issues-dev] CodeEnvy continues to use deceptive wording 
that's harmful to Eclipse

I was just reading the latest Microsoft/RedHat/Codenvy press release and came 
across the problematic wording that we’ve seen before.

Microsoft Visual Studio Code and Eclipse Che, the next-generation Eclipse IDE, 
have added support for the protocol.

https://www.redhat.com/en/about/press-releases/red-hat-codenvy-and-microsoft-collaborate-language-server-protocol

I think it’s great that Eclipse Foundation is getting more technologically 
diverse, but I find it very concerning that Eclipse Foundation is allowing 
Codenvy/Che to continue to use wording like this. Current Eclipse users will 
read this statement as an official statement of the roadmap for the desktop 
Eclipse IDE or whatever the hell we are supposed to call it now that Eclipse 
IDE doesn’t mean anything, apparently.

I understand why Codenvy would use wording like this as it helps them to 
promote Che. What I don’t understand is why Eclipse Foundation, through 
inaction, is allowing this to continue.

Thanks,

- Konstantin
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] New UUID in Eclipse Platform

[Doug Schaefer]

I'm neither for or against this. I do agree the communication was late. It
probably would have been better to not tell us at all :).

I do see the need for recognizing individual installs though. Tracking IP
address as we've done to date hides a lot of data behind corporate
firewalls that present a single address for all their employees.

I think it's critical we know how many individual users are using Eclipse.
Is Eclipse usage really on the decline? Are all those downloads legitimate
users or are they bots? I see a lot of statements made from the Eclipse
community assuming one way or the other. I would be great to be able to
call them out with real numbers.

Doug.

On Sat, Jun 4, 2016 at 10:59 AM, Gunnar Wagenknecht 
wrote:

> Ian,
>
> I agree with two concerns raised so far:
>
> - communication way too late in the cycle
> - opt-out instead of opt-in
>
> I do understand that opt-in renders the feature pretty much useless.
>
> On 04 Jun 2016, at 13:42, Ian Skerrett  wrote:
>
> We have no interest or plans to profile actual individuals. We are looking
> at aggregate data.
>
>
> I'm trying to understand why a UUID is necessary when you are looking at
> aggregate data. Do you have some sample reports/analysis for sharing? I'm
> really unable to connect the pieces of that puzzle. Maybe an example can
> help me understand.
>
> Also, have you investigated using an anonymized (hashed version) IP
> address that is sent by the clients anyway? Splunk should well be able to
> handle that.
>
> I also suggest to learn from history:
>
> http://news.softpedia.com/news/Google-Chrome-to-Remove-Unique-ID-137535.shtml
>
> http://www.theregister.co.uk/2010/03/16/google_chrome_unique_identifier_change/
>
> I bet they still have that UUID. But that's a use case I could understand.
> Even though I don't think that a UUID is really necessary to confirm
> successful installations/updates of a product.
>
> -Gunnar
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] New UUID in Eclipse Platform

[Doug Schaefer]

I'll add to that. You say this is in the Platform. Do you mean that all
products that build with the platform inherit this feature as well, not
just Eclipse released product?

On Fri, Jun 3, 2016 at 4:35 PM, Alexandre Montplaisir <
alexmon...@voxpopuli.im> wrote:

> Hi Ian,
>
> Sorry I will have to be "that guy", but I do find this a bit concerning.
>
> First, The eclipse.uuid file is put in the user's home directory, which
> means that it ends up identifying a *user*, not just an Eclipse
> installation. If the same user wipes his installation and re-installs
> another Ecilpse, he keeps the same ID.
>
> This is also done by default, with no warning to the user. Even
> proprietary programs often pop a window on the first run, asking the user
> if they want to provide anonymous usage statistics and the like, and giving
> them the option to disable it. Even if that option is enabled by default in
> the dialog, that is still miles better than not telling the user about it
> at all, and requiring him to know about an obscure "eclipse.uuid=0"
> configuration option.
>
>
> I realize I'm late to the party and the decision has already been made,
> but you said to let you know if we have questions or concerns, so I am
> doing just that ;)
>
> Regards,
>
> --
> Alexandre Montplaisir
> Trace Compass Committer & Project Lead
>
>
>
>
>
> On 2016-06-03 11:13 AM, Ian Skerrett wrote:
>
>> All,
>>
>> I wanted to make everyone aware that a UUID has been added to the Eclipse
>> Platform [1] and is available in the current Neon RC.  This was done at
>> the
>> request of the Eclipse Foundation.
>>
>>
>> The UUID is automatically generated and stored in the
>> ${user.home}/.eclipse/eclipse.uuid file. The UUID does not contain any
>> personally identifiable information. If a user do not want to have this
>> property set they are instructed to set eclipse.uuid=0. Information about
>> the UUID has been included in the Eclipse Platform N [2].
>>
>> The UUID will be automatically added to the user-agent of http requests to
>> *.eclipse.org servers. For Neon, the projects that make these types of
>> requests include p2 [1], MPC [3] and AERI [4]. I would expect other
>> projects
>> will add a uuid in the future.
>>
>>
>> The immediate questions for many people are 1) why are we doing this, and
>> 2)
>> what about the privacy concerns.  Let me attempt to answer both of these
>> questions.
>>
>> Why are we doing this?
>>
>> The Eclipse Foundation has started an program to better understand our
>> user
>> community. We are using a log file analysis service, Splunk, to analyze
>> many
>> of our log files to get a better idea of how people are using Eclipse. For
>> instance, how many people actively use Eclipse, what version of Java is
>> the
>> most popular with the Eclipse user community, what version of Eclipse
>> Platform is being used or what operating system is being used? In the
>> past,
>> this type of information was typically a 'best guess'. We believe can do
>> better by having the actual data of our user community. The UUID will
>> allow
>> us to get a more accurate answer to many of these questions.
>>
>> What about the privacy concerns?
>>
>> The UUID is anonymous and does not contain personably identifiable
>> information. We only intend to use and analyze the UUID at an aggregate
>> level. A user is able to opt-out of sending a UUID by setting
>> eclipse.uuid=0. The Eclipse Foundation has a published Privacy Policy [5]
>> that details our specific practices.
>>
>>   Please let me know if you have any questions or concerns. I appreciate
>> this
>> might be a sensitive topic but I do believe it is the right thing to do
>> for
>> the Eclipse community.
>>
>> Regards
>>
>> Ian
>>
>>
>>   [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=490112
>>
>> [2] https://www.eclipse.org/eclipse/news/4.6/platform.php
>>
>> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=492916
>>
>> [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=492917
>>
>> [4] https://eclipse.org/legal/privacy.php
>>
>>
>>
>>
>>
>> ___
>> 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 RC2 is complete

[Doug Schaefer]

Ooops, wrong list. :)

On Fri, May 27, 2016 at 11:23 AM, Doug Schaefer <cdtd...@gmail.com> wrote:

> +1 for CPP.
>
> On Fri, May 27, 2016 at 11:02 AM, Markus Knauer <mkna...@eclipsesource.com
> > wrote:
>
>> 10 out of 14 Eclipse Neon RC2 packages are now available from
>>
>>   https://www.eclipse.org/downloads/index-developer.php
>>
>> We'll enable the remaining ones as soon as a +1 from a package maintainer
>> arrives.
>>
>> Thanks,
>> Markus
>>
>> On 27 May 2016 at 16:15, David M Williams <david_willi...@us.ibm.com>
>> wrote:
>>
>>> We have "turned on" the repositories for Neon RC2 (which is now a
>>> composite of RC2, RC1, and M7).
>>>
>>> The EPP packages will be waiting a bit for some more mirrors to
>>> replicate, and 5 more package maintainers must give their +1 -- but, they
>>> should be available later this afternoon, AFAIK.
>>>
>>> Thank you, to all you contributors, for this "very close to the end"
>>> release candidate.
>>>
>>>
>>>
>>> ___
>>> 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 RC2 is complete

[Doug Schaefer]

+1 for CPP.

On Fri, May 27, 2016 at 11:02 AM, Markus Knauer 
wrote:

> 10 out of 14 Eclipse Neon RC2 packages are now available from
>
>   https://www.eclipse.org/downloads/index-developer.php
>
> We'll enable the remaining ones as soon as a +1 from a package maintainer
> arrives.
>
> Thanks,
> Markus
>
> On 27 May 2016 at 16:15, David M Williams 
> wrote:
>
>> We have "turned on" the repositories for Neon RC2 (which is now a
>> composite of RC2, RC1, and M7).
>>
>> The EPP packages will be waiting a bit for some more mirrors to
>> replicate, and 5 more package maintainers must give their +1 -- but, they
>> should be available later this afternoon, AFAIK.
>>
>> Thank you, to all you contributors, for this "very close to the end"
>> release candidate.
>>
>>
>>
>> ___
>> 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] Change 73676 insimrel/org.eclipse.simrel.build[master]: Update PTP to RC2

[Doug Schaefer]

I wonder if you ran into Hudson glitches. It's been really flaky today.

On Wed, May 25, 2016 at 9:32 PM, Greg Watson  wrote:

> I would have though everyone is using Gerrit by now, but I guess not.
>
> In any case, I’ve submitted another changeset, so hopefully it will work
> this time.
>
> Thanks,
> Greg
>
> On May 25, 2016, at 8:12 PM, David M Williams 
> wrote:
>
>
> > ... Does anyone know why, or how to fix it?
>
> My EGit contacts have not responded to my mail. Or a classic case of
> "committing, then going home" :) Or at least a classic case where a Gerrit
> submission would have helped! It would have caught the problem easily and
> prevented it from getting in the way of others. [I have seen that several
> times today, folks -- for all you who don't routinely use Gerrit -- please
> do!]
>
> I've taken my "best guess" as to what they intended. If my guess was
> wrong, they'll have to tell us that later, I guess.
>
> Thanks,
>
> ___
> 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] Incubation versus Orbit

[Doug Schaefer]

On Thu, May 12, 2016 at 10:55 PM, Wayne Beaton  wrote:

> A project can consume components from another incubating project.
>
> The limitation is that you can only consume components from a release
> version.
>
> Incubation is, however, viral. If a download includes bits from an
> incubating project, then the download needs to conform to the incubation
> branding requirements. e.g. if a package includes components from an
> incubating project, then the package must include a message along the lines
> of "includes incubating components".
>
> So, you can consume incubating components, but may not want to.
>

Which having done that, yes, you end up not wanting too. The impact on your
brand is quite damaging, speaking of EPP in particular. Which is too bad
since our users miss out on some potentially really cool features.


> HTH,
>
> Wayne
>
>
> On 12/05/16 07:00 PM, Wim Jongman wrote:
>
> Hi,
>
> Why are release train projects allowed to consume from Orbit but not from
> our own Incubation projects? A bundle in Orbit "states" that it is
> consumable from an IP POV but not from a quality POV. It is really up to
> the consumer of the Orbit project to assess and accept the quality of the
> Orbit bundle.
>
> All Incubation projects are also IP clean (and EPL). Why can (parts of)
> these projects not be consumed by release train projects?
>
> Cheers,
>
> Wim
>
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, 
> visithttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> --
> Wayne Beaton
> @waynebeaton
> The Eclipse Foundation
> [image: EclipseCon France 2016] 
>
> ___
> 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] Enforce Gerrit for Simrel?

[Doug Schaefer]

You can call them being lazy, but I call it being understaffed/underfunded.

While I agree with the technicalities of your argument Mickael, we have
also been very careful on the planning council not to put too much burden
on the projects. Forcing them to update all the versions they have in the
b3 agg file on every build is a non starter. We need to manage the balance
between the value of projects joining simrel against the costs. It's not
automatic.

- Doug.
___
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] Enforce Gerrit for Simrel?

[Doug Schaefer]

On Thu, Jan 7, 2016 at 12:08 PM, Konstantin Komissarchik <
konstantin.komissarc...@oracle.com> wrote:

> -1 to forcing the use of refs/for/x
>
>
>
> The validation results are unreliable as the aggregation build is not
> safely reproducible. A failed validation result is just as likely to be due
> to someone changing their already-contributed repository.
>

I don't really have a strong opinion here though I do favour everything
going through Gerrit just so that everyone who's watching the project in
Gerrit has visibility into what others are doing.

BTW, I can't agree with this argument about the verify jobs though. If jobs
are failing, we're in a world of hurt anyways. Maybe this will help raise
the visibility of that.

- Doug.


>
>
> Thanks,
>
>
>
> - Konstantin
>
>
>
>
>
>
>
>
> *From: *Mickael Istria 
> *Sent: *Thursday, January 7, 2016 8:03 AM
> *To: *cross-project-issues-dev@eclipse.org
> *Subject: *Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?
>
>
>
> On 01/07/2016 03:34 PM, David M Williams wrote:
>
> It is already 'required' that contributors "go though Gerrit" ... but it
> is allowed that the 'review/validation' can be skipped, if
> "refs/heads/master" used instead of "refs/for/master".
>
> Right, by enforcing Gerrit, I was meaning "enforcing review".
>
> But I myself would not like to see it *required* to go through
> "refs/for/master".
>
> Why so? Have you tried using it?
>
>
> I think most already do go through "refs/for/master" and the few times
> they do not
>
> It's about half-half:
> http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/log/ . All
> changes that don't have a "refs/changes/..." tag where pushed directly to
> master, without review and preliminary validation.
>
>
> I would assume they have a good reason for it.
>
> I would assume it's more that they need to be educated/encouraged/forced
> to use Gerrit.
>
>
> Can you point out (or monitor for) cases where people go directly to
> "refs/heads/master" and it causes problems?
>
> First, there are all failing builds that pre-dates Gerrit usage ;)
> I have troubles to identify where to get a history of the SimRel builds
> and to associate it with the actual commits that were involved. The CI jobs
> on http://hudson.eclipse.org/simrel do not show easy to consume data. Is
> there somewhere else I can look at to first get a list of recent-ish
> failure of simrel for Neon?
>
> --
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat 
> My blog  - My Tweets
> 
>
>
>
> ___
> 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] Enforce Gerrit for Simrel?

[Doug Schaefer]

On Thu, Jan 7, 2016 at 12:14 PM, Mickael Istria  wrote:

> On 01/07/2016 06:08 PM, Konstantin Komissarchik wrote:
>
> -1 to forcing the use of refs/for/x
>
> The validation results are unreliable as the aggregation build is not
> safely reproducible. A failed validation result is just as likely to be due
> to someone changing their already-contributed repository.
>
> Is there a bug on the topic of unreliable validation results? I agree that
> having them reliable seems to be a preliminary requirement.
> By the way, some time ago, we discussed the idea of policies about
> contributing immutable URLs and fully qualified versions to Simrel, in
> order to provide predictability and reproducibility. Have these ideas been
> abandoned? If we were to enforce review, we could put additional checks to
> verify at least that versions are fully qualified.
>

The planning council has made this a requirement for Neon. I'm not sure how
enforceable this is going to be but if everyone follows the rules, the
aggregate build will be reproducible.


>
> --
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat 
> My blog  - My Tweets
> 
>
> ___
> 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 asked if I trust the Eclipse signing certificate, if I want to install something

[Doug Schaefer]

It's all the chain of trust. The root certificate, the one at the bottom,
should be in your JVM's collection of trusted certificates. Each one signs
the one above until you get to the top one which is the one used to sign
the jars. As long as the JVM can follow that chain to one it knows, it'll
pass the verification.

BTW, this has nothing to do with p2. p2 just uses the facilities the JVM
provides.

On Thu, Dec 17, 2015 at 9:37 AM, Lars Vogel  wrote:

> > Did you check the JVM and their trusted certificates? Any changes and/or
> updates there?
>
> Thanks for the answer Markus. I will have a look, so far I wasn't even
> aware that the JVM has its own trusted certificates. I always assumed
> Eclipse has this implemented as part of p2.
>
> Best regards, Lars
>
> On Thu, Dec 17, 2015 at 12:38 PM, Markus Knauer
>  wrote:
>
> > Are the root certificates that are mentioned in the certificate chain
> > trusted?
> >
> > I tried it with my own Mars.1 RCP/RAP package and it worked without
> showing
> > me this dialog.
> >
> > Regards,
> > Markus
> >
> >
> > On 17 December 2015 at 11:50, Lars Vogel  wrote:
> >>
> >> Recently Eclipse started to ask me to confirm that I trust the Eclipse
> >> certificate, if I want to install something.
> >>
> >> Example: Using 4.5.1.M20150904-0015 under Ubuntu 15.10 while
> >> installing Wikitext support from
> >> http://download.eclipse.org/mylyn/snapshots/weekly
> >>
> >> Is this expected? I used to be that the Eclipse IDE would trust
> >> Eclipse signed content automatically
> >>
> >> Best regards, Lars
> >>
> >> --
> >> Eclipse Platform UI and e4 project co-lead
> >> CEO vogella GmbH
> >>
> >> Haindaalwisch 17a, 22395 Hamburg
> >> Amtsgericht Hamburg: HRB 127058
> >> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> >> USt-IdNr.: DE284122352
> >> Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web:
> >> http://www.vogella.com
> >>
> >> ___
> >> 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
>
>
>
> --
> Eclipse Platform UI and e4 project co-lead
> CEO vogella GmbH
>
> Haindaalwisch 17a, 22395 Hamburg
> Amtsgericht Hamburg: HRB 127058
> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> USt-IdNr.: DE284122352
> Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web:
> http://www.vogella.com
> ___
> 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] [tm-dev] Any RSE dependencies in Neon?

[Doug Schaefer]

Currently I think CDT does. But we should really remove that if it¹s still
there.

Doug.

On 2015-12-11, 1:13 PM, "tm-dev-boun...@eclipse.org on behalf of Greg
Watson" 
wrote:

>Are there any projects that have a dependency on Remote System Explorer
>(RSE) in Neon? The TM project must decide if RSE will be included in the
>Neon release. Currently there is only interest in including TM Terminal.
>
>Thanks,
>Greg
>___
>tm-dev mailing list
>tm-...@eclipse.org
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.eclipse.org/mailman/listinfo/tm-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] Eierlegende Wollmilchsau

[Doug Schaefer]

As I mentioned, I turn off almost all the other buttons on every perspective. 
Only a few editor ones remain that have no equivalent in the menus or keyboard 
shortcuts. Doing that, it actually looks OK, since there are only 5 or 6 of the 
little ones left.

And besides, I could make it the same 16 pixel size but it would look like 
crap, just like the New Connection… item in Michael’s picture (which comes from 
RSE or TCF, BTW).

The end objective is to present something pleasant to the user’s eye with 
images that make sense to them. Consistency is a means to an end, it is not the 
end in itself. Happy users is the end :).

And, again, if someone can propose something better, I’d love to try it out. 
For me, the most important thing is the workflow that the launch bar enables 
almost eliminating the need for the user to go to the launch configuration 
dialog, and to tie what is being built with what, where, and how the user wants 
to launch it, something especially important to developers working with remote 
devices and servers. I am less tied to how it looks, as long as it doesn’t look 
like crap.

Doug.

From: 
<cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>>
 on behalf of Lars Vogel <lars.vo...@vogella.com<mailto:lars.vo...@vogella.com>>
Reply-To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Date: Wednesday, December 9, 2015 at 12:53 PM
To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Subject: Re: [cross-project-issues-dev] Eierlegende Wollmilchsau


I agree, that the bug lauchbar icons looks displaced.

Doug, IIRC you usually a argue for consistency in the IDE. IMHO these lauchbar 
icons should use the same size as all the others, otherwise they are a UI 
breakage for the user.

We in Platform plans to bring high resolution support for icons in the Neon 
release (IIRC Markus Keller works on this.

Best regards, Lars

Am 09.12.2015 5:30 nachm. schrieb "Ed Merks" 
<ed.me...@gmail.com<mailto:ed.me...@gmail.com>>:
Doug,

Comments below.

On 09/12/2015 4:58 PM, Doug Schaefer wrote:
Thanks Ed! (and Michael for the picture).
It was kind of entertaining.  In any case, we generate this product along with 
the rest of the product catalog, so it will always be available for testing.
This is awesome and I’m glad we’re finally talking about this. In fact, I think 
we also need to go beyond the contents of the simrel repo and also consider 
popular 3rd party plug-ins, Pydev and Nodeclipse come to mind. And Andmore 
which is coming in Neon will also make this much worse and I’m planning on 
helping clean that up.
Yes, unfortunately once it's installed, it's just all "Eclipse" to the end 
user, so if others mess things up, they mess it up for all of us...

You bring up a great point about the Toolbar. It’s the most obvious affect of 
the tragedy of the commons, and it’s why I’m having a personal war against it. 
Do these buttons really need to be in the face of the user all the time?
I would say not, and certainly not in every perspective either.
How often are any of these actually used versus the real estate they take up.
Indeed.
Wouldn’t it look better if we had fewer toolbar buttons but make them a little 
bit larger to make them easier to understand for new users?
I actually like them small.  But there's no accounting for personal taste.   Of 
course there could be a preference for toolbar button size (like Windows has 
for the task icons, which I have set to small), but unless an army of graphic 
designers make nicer large icons, that will probably look crappy.
How do we make this better?
Get everyone to agree on the one way that's best. :-P   With EMF I took pains 
to ensure that it has no visible footprint when installed.   For Oomph we also 
tried to minimize visual footprint, so the toolbar buttons we really like (and 
that are super handy, if you're actually using Oomph) are not visible by 
default, but are easily made visible via a preference (and of course that 
preference can be recorded so I always see it and  you never do).

While on the topic, one of the horrible things I always hit is those navigator 
toolbar buttons that I use a lot, but it navigates to a different editor, which 
has different toolbar contributions, so the navigator buttons move, and I have 
to hunt it down again, or hit the wrong button.  It's super frustrating.

And yes, the Launch Bar. Lots of Eclipse veterans complain about how it doesn’t 
fit in with the rest of the toolbar.
It definitely doesn't fit in.  But I understand the design intent is good.
But take a look at the New Connection… item and how it really doesn’t fit in 
the 16 pixel height. It looks horrible.
Where does it come from? My IDEs never have that, but of course I mostly use 
the committers package with some 

Re: [cross-project-issues-dev] Eierlegende Wollmilchsau

[Doug Schaefer]

I have and you¹ve mentioned that in the past. Consider it considered. I
know there¹s an issue and, for the record, I haven¹t said what we have now
is not crap (and it¹s not my button, BTW, there¹s small team working on
this). But I am still waiting for something better ;).

Also, I think it depends on what kind of user you are. There are people
who don¹t mind it at all and rather like it. Building and Launching are
what many users do quite regularly. Java users probably never build, but
they do launch. Eclipse developers probably have the least use for this
since they only have one launch configuration, though if you¹re running
JUnits...

I have on my todo list to create a video showing it in action. I use it
constantly and work with lots of different types of projects from Eclipse
to pure Java for cloud micro services to Maven builds (which turns out
kind of make sense as a launch, especially if you¹re building a Mojo) to
C/C++ for many platforms. It would be good to show it off and maybe it¹ll
spark in someone a way to make it not look like crap.

Thanks!
Doug.

On 2015-12-09, 4:21 PM, "cross-project-issues-dev-boun...@eclipse.org on
behalf of Lars Vogel" <cross-project-issues-dev-boun...@eclipse.org on
behalf of lars.vo...@vogella.com> wrote:

>Doug, please take this as one data point from an IDE user.
>
>Personally as an Eclipse user I think the new icons do not look good
>and make the Eclipse UI look bad. The phrase you used "look like crap"
>seems fitting, if there is at least one other icon displayed with it.
>Also the colors selected for the buttons makes them "very outstanding"
>IMHO in a negative way. The item of my focus as an Eclipse user should
>not be your button.
>
>I agree the New ConnectionŠ item also looks bad.
>
>Best regards, Lars
>
>On Wed, Dec 9, 2015 at 7:16 PM, Doug Schaefer <dschae...@qnx.com> wrote:
>> As I mentioned, I turn off almost all the other buttons on every
>> perspective. Only a few editor ones remain that have no equivalent in
>>the
>> menus or keyboard shortcuts. Doing that, it actually looks OK, since
>>there
>> are only 5 or 6 of the little ones left.
>>
>> And besides, I could make it the same 16 pixel size but it would look
>>like
>> crap, just like the New ConnectionŠ item in Michael¹s picture (which
>>comes
>> from RSE or TCF, BTW).
>>
>> The end objective is to present something pleasant to the user¹s eye
>>with
>> images that make sense to them. Consistency is a means to an end, it is
>>not
>> the end in itself. Happy users is the end :).
>>
>> And, again, if someone can propose something better, I¹d love to try it
>>out.
>> For me, the most important thing is the workflow that the launch bar
>>enables
>> almost eliminating the need for the user to go to the launch
>>configuration
>> dialog, and to tie what is being built with what, where, and how the
>>user
>> wants to launch it, something especially important to developers working
>> with remote devices and servers. I am less tied to how it looks, as
>>long as
>> it doesn¹t look like crap.
>>
>> Doug.
>>
>> From: <cross-project-issues-dev-boun...@eclipse.org> on behalf of Lars
>>Vogel
>> <lars.vo...@vogella.com>
>> Reply-To: Cross project issues <cross-project-issues-dev@eclipse.org>
>> Date: Wednesday, December 9, 2015 at 12:53 PM
>> To: Cross project issues <cross-project-issues-dev@eclipse.org>
>> Subject: Re: [cross-project-issues-dev] Eierlegende Wollmilchsau
>>
>> I agree, that the bug lauchbar icons looks displaced.
>>
>> Doug, IIRC you usually a argue for consistency in the IDE. IMHO these
>> lauchbar icons should use the same size as all the others, otherwise
>>they
>> are a UI breakage for the user.
>>
>> We in Platform plans to bring high resolution support for icons in the
>>Neon
>> release (IIRC Markus Keller works on this.
>>
>> Best regards, Lars
>>
>> Am 09.12.2015 5:30 nachm. schrieb "Ed Merks" <ed.me...@gmail.com>:
>>>
>>> Doug,
>>>
>>> Comments below.
>>>
>>> On 09/12/2015 4:58 PM, Doug Schaefer wrote:
>>>
>>> Thanks Ed! (and Michael for the picture).
>>>
>>> It was kind of entertaining.  In any case, we generate this product
>>>along
>>> with the rest of the product catalog, so it will always be available
>>>for
>>> testing.
>>>
>>> This is awesome and I¹m glad we¹re finally talking about this. In
>>>fact, I
>>> think we also need to go beyond the contents of the simrel repo and

Re: [cross-project-issues-dev] Eierlegende Wollmilchsau

[Doug Schaefer]

If the toolbar buttons could resize up to 24 pixels, say, then we probably 
wouldn't have an issue. We could make them all the same size and leave enough 
margin for things to look good. Making them smaller than 16 pixels will make 
them even more useless.

I'm going to try and bring things down to 24 pixel and see what it looks like. 
Might not be as much of a shock.

BTW, please raise bugs and we can discuss this in bugzilla. Right now we're in 
CDT component cdt-other, until I find a better home for it.

Thanks for the feedback all. Much appreciated and food for thought.
Doug.

From: Wayne Beaton <wa...@eclipse.org<mailto:wa...@eclipse.org>>
Date: Wed Dec 09 2015 17:10:22 GMT-0500 (EST)
To: cross-project-issues-dev@eclipse.org 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Subject: Re: [cross-project-issues-dev] Eierlegende Wollmilchsau

I think that there's a bug open to make the tool bar button size dynamically, 
primarily to make them usable on hidpi monitors. Are this and the combo box 
size issue related?

Wayne

On 09/12/15 05:04 PM, Doug Schaefer wrote:

From: 
<<mailto:cross-project-issues-dev-boun...@eclipse.org>cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>>
 on behalf of Wayne Beaton <wa...@eclipse.org<mailto:wa...@eclipse.org>>
Organization: The Eclipse Foundation
Reply-To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Date: Wednesday, December 9, 2015 at 4:44 PM
To: 
"<mailto:cross-project-issues-dev@eclipse.org>cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>"
 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Subject: Re: [cross-project-issues-dev] Eierlegende Wollmilchsau

Is maybe the first step to make it look and act like everything that's already 
on the tool bar?

The New Connection is what it would look like and -1 to that.

The issue is that you’re showing 16 pixel high images and text in a combo 
boxes. You need at least two pixels of margin to make that look good plus the 
border giving you 22 pixels high, right now there’s 5 pixels of margin height 
giving us more like 28 pixels. Given that buttons are 32 pixels square, it’s a 
little unbalanced as it is. But you can’t really have the buttons smaller than 
the combos. That would look dumb.



Frankly, I like the idea of pushing the metaphors that we use and challenging 
look and feel assumptions. I actually quite like the look of the Launch Bar. It 
does, however, stand out like a sore thumb.

You should have heard what the UX designers we were working with though of the 
current Eclipse look and feel (a bunch of crazy Swedes from Malmo :) ). They 
insisted that all images should be no smaller than 32 pixel and all icons that 
you hardly use should be removed. We’ve already toned down the original design. 
If you get a chance, take a look at the first BlackBerry Momentics IDE that the 
launch bar appeared in. When our product manager first showed it at a dev 
conference, one of the audience members came up after and gave him a hug 
thanking him for all the great work we’ve done to make it easier to use. You 
know you’re doing something right when that happens.



The buttons need to be reactive.

Yup, I there’s a bug open on that already.



Wayne

On 09/12/15 04:32 PM, Doug Schaefer wrote:

It would be good to show it off and maybe it¹ll
spark in someone a way to make it not look like crap.

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseCon NA 2016]<http://www.eclipsecon.org/na2015>
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.



___
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

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseConNA 2016]<http://www.eclipsecon.org/na2015>
-
This transmission (including any attachme

Re: [cross-project-issues-dev] File server down?

[Doug Schaefer]

Yeah, it’s a pain in the you know what right now as I try to get a build ready 
for my IoT meetup tomorrow. Finally getting a clean one.

D

From: 
>
 on behalf of Ian Bull 
>
Reply-To: Cross project issues 
>
Date: Tuesday, December 1, 2015 at 10:14 PM
To: Cross project issues 
>
Subject: Re: [cross-project-issues-dev] File server down?

I'm seeing this too. It's rather intermittent though.

On Tue, Dec 1, 2015 at 12:16 PM, Pascal Rapicault 
> wrote:
When running the Egerrit build, I get a number of errors like the following
Caused by: org.eclipse.equinox.p2.core.ProvisionException: HTTP Server 
'Service 
Unavailable':http://download.eclipse.org/tools/orbit/downloads/drops/R20150519210750/repository/content.xml.xz

Is this something known?

___
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



--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource
___
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] 1000 line limit for contributions

[Doug Schaefer]

We need to keep in mind the spirit of the rule which is as Pascal mentioned. I 
always thought the lines of code was a guideline and certainly doesn’t excuse 
the committer from taking a good look at the code and even if it’s less than 
1000 lines, if it looks like a algorithm that could be taken from somewhere 
else that it gets reviewed.

From: 
>
 on behalf of Fred Bricon >
Reply-To: Cross project issues 
>
Date: Thursday, November 19, 2015 at 10:12 AM
To: Cross project issues 
>
Subject: Re: [cross-project-issues-dev] 1000 line limit for contributions

I'm not sure how the workload from the IP team is split, between running 
automated IP checks (blackduck or similar) and manual work. But I think it'd be 
interesting if at least the automated part could be included as part of a CI 
build checking gerrit contributions. That'd would surely offload the IP team 
work significantly.

On Thu, Nov 19, 2015 at 10:01 AM, Pascal Rapicault 
> wrote:
It is my understanding that the 1000 lines limit is here to prevent code to be 
copied from an external place and be added to Eclipse.  This is a good measure.
However, I think there is a number of contributions where the code has 
obviously not been copied. For example, this is the case with the contribution 
Jan mentioned. There is no way the code could be coming from somewhere else. It 
is way too specific to Tycho and the feature being added.

IMO, the IP process could be relaxed and thus the IP teamwork load reduced, if 
committers were trusted on what to put through the IP process and what not.

With such a rule, a committer who has doubts about 200 lines of code could take 
it through the IP process, and yet for things that are obviously "new" code, 
would not. IMO, such a process based on committer trust could help focus the 
efforts of the IP team on things that are potentially problematic.




On 15-11-19 05:47 AM, Ed Merks wrote:
Yes, I believe it's an important aspect of Eclipse that makes it stand out as 
the best place to be if you want the broadest possible community of adopters.   
Of course this benefit doesn't come without a cost and of course that can be 
frustrating.   In a specific case of a contribution that consists of a 
relatively smaller changes to the framework/tool with a relatively larger 
addition of test case(s), it would seem reasonable to split the two, if it's 
important that the change to the tools/framework show up as quickly as possible.

I certainly don't suggest gaming the system, though I do tend to point out to 
the IP committee all the ways it can be gamed, and will be gamed by developers 
who are frustrated and don't take the issue seriously.  I ask questions such as 
how long can a line be? One can fit quite a lot on a line line and reformat it 
later. Also, why should a blank line count for anything?  Is a line with just a 
curly brace on it really IP?   And yes, of course I make them aware that 
contributions can be split into smaller chunks...

Perhaps this specific review period overlapped with EclispeCon Europe where we 
had the pleasure of spending personal time with the with the IP staff...


On 19/11/2015 11:31 AM, Christian Campo wrote:
Wouldnt it be worth to hear what the IP Team has to say why this took so
long ? I see that Sharon appologized on the CQ that it took so long. That
made me believe that this was an exception.

Does every CQ with 1000 lines take so long ? What is the experience of
others about reviews with code contributions.
As I remember vaguely (and that might be incorrect) the IP team runs
automatic scans over the code, but I am not sure what else they do.

I for once believe the work of the IP Team is important and one of the
core values of the EF vs say Github and I take it serious.

Just my 2 cents

christian

Am 19.11.15, 11:22 schrieb 
"cross-project-issues-dev-boun...@eclipse.org
on behalf of Sievers, Jan" unter

 on behalf of
jan.siev...@sap.com>:

If everybody tells me there are ways to dodge around that rule (and of
course I know there are), the question arises why do we have the rule in
the first place. Seems a little absurd to me.

the effort is not minimal if I have to artificially split up commits.
Or maybe you expect me to explain to contributors:

"look, we have this process but nobody takes it serious anyway. so please
split up your commit into several < 1000 LOC chunks" ?

Best Regards,
Jan



On 19/11/15 11:00, 

Re: [cross-project-issues-dev] Announcing Andmore participation in Neon

[Doug Schaefer]

From: 
<cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>>
 on behalf of Doug Schaefer <dschae...@qnx.com<mailto:dschae...@qnx.com>>
Reply-To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Date: Thursday, November 12, 2015 at 4:56 PM
To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Subject: [cross-project-issues-dev] Announcing Andmore participation in Neon

Andmore, the Eclipse for Android project, will be participating in Neon.

https://projects.eclipse.org/projects/tools.andmore/releases/1.0-neon

Offset is + a bunch since it depends on at least one +3 project.

Not we’ll also try and graduate at this point.

Well, more a note than not. BTW, we’re also intending on creating an EPP 
package for an IDE for Android by M4, cross our fingers.


Thanks,
The Andmore Gang

From: 
<cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>>
 on behalf of Wayne Beaton <wa...@eclipse.org<mailto:wa...@eclipse.org>>
Organization: The Eclipse Foundation
Reply-To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Date: Tuesday, October 27, 2015 at 12:03 AM
To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Subject: [cross-project-issues-dev] Announcing participation in Neon

Greetings folks.

It's that time of year! The opt-in deadline for Neon is M4 on December 18. 
Opt-in early! Avoid the rush!

We decided a few years ago to require every project that's participating in the 
release to explicitly opt-in to participation. This was done primarily because 
we always ended up with a handful of projects that carried over from a previous 
year, but didn't pay attention to the communication (I believe that in most 
cases, the projects didn't have representation on this list). By making project 
teams opt-in explicitly, we had a means of finding out early if had to chase 
somebody down.

The requirements for participation are documented in the Simultaneous Release 
Requirements document [1]. For good measure, I also added them to the new 
Eclipse Project Handbook [2].

The short version is: make a release record in the PMI and announce your plan 
on this list along with your offset. I take it from there. Note that you can 
change the version number that you use on the release record and everything 
will just work (if, for example, you're not sure then just pick a number and 
change it when you are sure).

I'm assembling the list of participating projects here:

https://projects.eclipse.org/releases/neon

If your project is not listed, or any of the information is wrong, let me know 
(either by direct communication or via this list).

Wayne

[1] 
https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#State_intent_early_.28M4.29
[2] 
https://www.eclipse.org/projects/handbook/#pmi-joining-a-simultaneous-release
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseConEurope 2015]<http://www.eclipsecon.org/europe2015>
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
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] Announcing Andmore participation in Neon

[Doug Schaefer]

Andmore, the Eclipse for Android project, will be participating in Neon.

https://projects.eclipse.org/projects/tools.andmore/releases/1.0-neon

Offset is + a bunch since it depends on at least one +3 project.

Not we’ll also try and graduate at this point.

Thanks,
The Andmore Gang

From: 
>
 on behalf of Wayne Beaton >
Organization: The Eclipse Foundation
Reply-To: Cross project issues 
>
Date: Tuesday, October 27, 2015 at 12:03 AM
To: Cross project issues 
>
Subject: [cross-project-issues-dev] Announcing participation in Neon

Greetings folks.

It's that time of year! The opt-in deadline for Neon is M4 on December 18. 
Opt-in early! Avoid the rush!

We decided a few years ago to require every project that's participating in the 
release to explicitly opt-in to participation. This was done primarily because 
we always ended up with a handful of projects that carried over from a previous 
year, but didn't pay attention to the communication (I believe that in most 
cases, the projects didn't have representation on this list). By making project 
teams opt-in explicitly, we had a means of finding out early if had to chase 
somebody down.

The requirements for participation are documented in the Simultaneous Release 
Requirements document [1]. For good measure, I also added them to the new 
Eclipse Project Handbook [2].

The short version is: make a release record in the PMI and announce your plan 
on this list along with your offset. I take it from there. Note that you can 
change the version number that you use on the release record and everything 
will just work (if, for example, you're not sure then just pick a number and 
change it when you are sure).

I'm assembling the list of participating projects here:

https://projects.eclipse.org/releases/neon

If your project is not listed, or any of the information is wrong, let me know 
(either by direct communication or via this list).

Wayne

[1] 
https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#State_intent_early_.28M4.29
[2] 
https://www.eclipse.org/projects/handbook/#pmi-joining-a-simultaneous-release
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseConEurope 2015]
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
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] Did I mess up our procedure for Neon? With respect to declaring, and enablement, and our "list of participants"?

[Doug Schaefer]

A man after my own heart :).

I can’t remember if CDT declared for Neon. It’ll be a sad day the release we 
don’t.

Doug.

From: 
>
 on behalf of Thomas Watson >
Reply-To: Cross project issues 
>
Date: Wednesday, October 21, 2015 at 11:27 AM
To: Cross project issues 
>
Subject: Re: [cross-project-issues-dev] Did I mess up our procedure for Neon? 
With respect to declaring, and enablement, and our "list of participants"?

Not sure you noticed but Equinox only declared for Neon just now.  Would have 
been interesting to see what happens if you disabled Equinox.

Tom





From:David M Williams/Raleigh/IBM@IBMUS
To:
cross-project-issues-dev@eclipse.org
Date:10/21/2015 09:15 AM
Subject:[cross-project-issues-dev] Did I mess up our procedure for 
Neon? With respect to declaring, and enablement, and our "list of participants"?
Sent by:
cross-project-issues-dev-boun...@eclipse.org




Just today I realized I think I was supposed to "disable" everyone, until they 
responded affirmatively that they were participating in Neon.

Since so many have declared their intent already, I hate to start over, by 
disabling everyone, but, need to come up with a list of "those who have 
declared intent",
and then I will disable the rest.

Wayne have you been keeping track? So far, the list at
https://projects.eclipse.org/releases/neon
only shows "Eclipse" is participating. I assume that's set to always be true. :)
But the rest need someone to enter the data?

If we can get a better list in next week or so, then by M3 I will disable 
anyone who has not yet declared intent.
For example, perhaps BIRT is no longer planning to participate? (For all I 
know?)

Thanks,

___
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] Did I mess up our procedure for Neon? With respect to declaring, and enablement, and our "list of participants"?

[Doug Schaefer]

:). Thanks, Marc.

BTW, my point really is that I don’t think it should be so easy for projects to 
come and go on the release train. Assuming people are using the contributions 
of the project, it would be unsettling for them to be removed all of a sudden 
in the next release. If the impact is small, then you need to ask whether they 
should have been on the train to begin with. Stuff happens, I get that. But 
something to think about. And probably a discussion for the planning council.

Doug.

From: 
<cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>>
 on behalf of Marc Khouzam 
<marc.khou...@ericsson.com<mailto:marc.khou...@ericsson.com>>
Reply-To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Date: Wednesday, October 21, 2015 at 12:39 PM
To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Subject: Re: [cross-project-issues-dev] Did I mess up our procedure for Neon? 
With respect to declaring, and enablement, and our "list of participants"?

We did declare CDT for Neon, referring to your now famous line :-)

"CDT will be in every simultaneous release from the first one until forever. "


https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg12209.html


From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 
[cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>]
 on behalf of Doug Schaefer [dschae...@qnx.com<mailto:dschae...@qnx.com>]
Sent: October 21, 2015 11:43 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Did I mess up our procedure for Neon? 
With respect to declaring, and enablement, and our "list of participants"?

A man after my own heart :).

I can’t remember if CDT declared for Neon. It’ll be a sad day the release we 
don’t.

Doug.

From: 
<cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>>
 on behalf of Thomas Watson <tjwat...@us.ibm.com<mailto:tjwat...@us.ibm.com>>
Reply-To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Date: Wednesday, October 21, 2015 at 11:27 AM
To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Subject: Re: [cross-project-issues-dev] Did I mess up our procedure for Neon? 
With respect to declaring, and enablement, and our "list of participants"?

Not sure you noticed but Equinox only declared for Neon just now.  Would have 
been interesting to see what happens if you disabled Equinox.

Tom





From:David M Williams/Raleigh/IBM@IBMUS
To:
cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>
Date:10/21/2015 09:15 AM
Subject:[cross-project-issues-dev] Did I mess up our procedure for 
Neon? With respect to declaring, and enablement, and our "list of participants"?
Sent by:
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>




Just today I realized I think I was supposed to "disable" everyone, until they 
responded affirmatively that they were participating in Neon.

Since so many have declared their intent already, I hate to start over, by 
disabling everyone, but, need to come up with a list of "those who have 
declared intent",
and then I will disable the rest.

Wayne have you been keeping track? So far, the list at
https://projects.eclipse.org/releases/neon
only shows "Eclipse" is participating. I assume that's set to always be true. :)
But the rest need someone to enter the data?

If we can get a better list in next week or so, then by M3 I will disable 
anyone who has not yet declared intent.
For example, perhaps BIRT is no longer planning to participate? (For all I 
know?)

Thanks,

___
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

Re: [cross-project-issues-dev] Maintenance builds (was Announcing a one week slip in the Mars.1 release (from 9/25 to 10/2))

[Doug Schaefer]

No, maintenance releases are still necessary. But you have to ask yourself, why 
are we synchronizing them.

I think on another thread here we have the solution. Projects need to be free 
to release maintenance releases at any time. We have the technology to make 
Check for Updates work to find them. It's probably a bad idea to synchronize 
them. Why wait for others if you have an update ready to go?

The main concern we've had is whether we can scale to have Check for Updates 
check p2 repos for every project whose features you have installed. But that 
could be an area we could invest in.

It's also worrisome if projects release updates that break other projects. The 
simultaneous release helped with that by getting everyone to test the entire 
stack being released. But I'm not sure how big a problem that really is and 
hopefully allowing spontaneous maintenance releases can help fix those problems 
quickly.

Doug

From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Stephan Herrmann 
[stephan.herrm...@berlin.de]
Sent: Thursday, September 24, 2015 1:37 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Maintenance builds (was Announcing a 
one week slip in the Mars.1 release (from 9/25 to 10/2))

Hi,

I don't see an easy solution but I do share Ed's concerns in this regard.

Is this just a packaging issue or an issue of content?
Aside from the Eclipse project, how many projects are actively
maintaining maintenance branches (no pun intended)?
Meaning: if we'd provide a channel for obtaining maintenance
updates only, what would be the content of the channel,
only platform updates?
Do projects with a lower offset within SimRel perhaps
care more about maintenance than "leaf" projects?

Honestly tell me: Is doing maintenance releases a relic from
the olden days in an ever accelerating world?

Stephan

On 09/24/2015 05:13 PM, Ed Willink wrote:
> Hi
>
> That makes sense but shows that we are just shifting the problem.
>
> I see a requirement for
> - regular base releases (yearly)
> - maintenance releases (four monthly)
> - responsive releases (four monthly)
>
> Recognising that maintenance releases were being abused to provide responsive 
> releases is probably good, but waving goodbye to
> maintenance releases is bad.
>
> IMHO we need all three and so long as we try to make do with two we will be 
> in trouble with some user community. It seems wrong that
> because some projects have abused the principles of maintenance, users of 
> other projects that have observed maintenance discipline
> suffer.
>
>  Regards
>
>  Ed Willink
>
> On 24/09/2015 15:35, Ian Bull wrote:
>> Ed,
>>
>> The reason for the change from Mars SR1 to Mars 1 is because this is how 
>> we've been doing it for years. Many people (EGit / JGit,
>> Mylyn, CDT -- to name a few) had been putting minor releases in the release 
>> train during the SRs. I ran some numbers last year,
>> and > 1000 Installable Units had incremented their minor version number 
>> between SR0 and SR2. This means, assuming people are
>> following the version guidelines, that up to 1,000 bundles had already been 
>> adding new API between SR0 and SR2.
>>
>> Changing the name of the train just means we are acknowledging what was 
>> already happening.
>>
>> Cheers,
>> Ian
>>
>> On Wed, Sep 23, 2015 at 11:21 PM, Ed Willink > > wrote:
>>
>> HI
>>
>> Surely this is the inevitable consequence of Mars.1 rather than Mars SR1?
>>
>> SR1 required each component to be a safe upgrade so that exact release 
>> timing was irrelevant.
>>
>> Mars.1 is a new release so users must get to see the co-ordinated new 
>> release in one go rather than incrementally. If A.1
>> pulls in B.1, but C uses B, users of C are in a mess until they get C.1.
>>
>> Regards
>>
>> Ed Willink
>>
>>
>>
>> On 24/09/2015 05:26, Gunnar Wagenknecht wrote:
>>
>> David,
>>
>> Am 23.09.2015 um 23:37 schrieb David M Williams 
>> <david_willi...@us.ibm.com>:
>> If not obvious, this means all participants in "coordinated 
>> release train" should not make your releases visible on
>> 9/25, but wait until 10/2 10 AM to make them visible, and 
>> announce your official releases.
>>
>> This seem unnecessarily restrictive. I don't bother with the 
>> announcement part. However, I don't recall there is something
>> in the process that requires project to wait publishing the release 
>> bits. Not making them visible could have a huge effect
>> on a project's adopter community.
>>
>> -Gunnar
>>
>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org 
>> 

Re: [cross-project-issues-dev] Announcing a one week slip in the Mars.1 release (from 9/25 to 10/2)

[Doug Schaefer]

BTW, yes this is a consequence of moving to Mars.1. So is getting Gradle 
support into Eclipse now and not in 9 months. In the big picture, we figure it 
works out to a net benefit to our users and adopters.

Doug.


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Ian Bull 
[irb...@eclipsesource.com]
Sent: Thursday, September 24, 2015 10:35 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Announcing a one week slip in the 
Mars.1 release (from 9/25 to 10/2)

Ed,

The reason for the change from Mars SR1 to Mars 1 is because this is how we've 
been doing it for years. Many people (EGit / JGit, Mylyn, CDT -- to name a few) 
had been putting minor releases in the release train during the SRs. I ran some 
numbers last year, and > 1000 Installable Units had incremented their minor 
version number between SR0 and SR2. This means, assuming people are following 
the version guidelines, that up to 1,000 bundles had already been adding new 
API between SR0 and SR2.

Changing the name of the train just means we are acknowledging what was already 
happening.

Cheers,
Ian

On Wed, Sep 23, 2015 at 11:21 PM, Ed Willink 
> wrote:
HI

Surely this is the inevitable consequence of Mars.1 rather than Mars SR1?

SR1 required each component to be a safe upgrade so that exact release timing 
was irrelevant.

Mars.1 is a new release so users must get to see the co-ordinated new release 
in one go rather than incrementally. If A.1 pulls in B.1, but C uses B, users 
of C are in a mess until they get C.1.

Regards

Ed Willink



On 24/09/2015 05:26, Gunnar Wagenknecht wrote:
David,

Am 23.09.2015 um 23:37 schrieb David M Williams 
>:
If not obvious, this means all participants in "coordinated release train" 
should not make your releases visible on 9/25, but wait until 10/2 10 AM to 
make them visible, and announce your official releases.
This seem unnecessarily restrictive. I don't bother with the announcement part. 
However, I don't recall there is something in the process that requires project 
to wait publishing the release bits. Not making them visible could have a huge 
effect on a project's adopter community.

-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



--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource
___
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

[Doug Schaefer]

On 2015-09-23, 8:41 AM, "cross-project-issues-dev-boun...@eclipse.org on
behalf of Ed Willink"  wrote:

>Hi
>
>[I'm not clear why a new product is a problem with a 'maintenance'
>release; I guess I've become too accustomed to traditional Eclipse
>practices..]

Or you missed the memo that these aren¹t maintenance releases anymore.
Another sign we really need to improve our communication around this.

Doug

>
>But given that it is there, this seems to be exactly why we have a quiet
>week. Let's fix it. The fix seems very low risk, and conversely the
>non-fix has high reputational impact.
>
>+1 for a respin.
>
> Regards
>
> Ed Willink
>
>On 23/09/2015 11:08, Martin Lippert wrote:
>> Hey!
>>
>> Strong +1 for a re-spin.
>>
>> Cheers,
>> -Martin
>>
>>
>>
>>> Am 23.09.2015 um 12:04 schrieb Simon Scholz :
>>>
>>> Hi,
>>>
>>> the steps to reproduce the issue are:
>>>
>>> 1) Install Buildship with the version you want to test
>>> 2) Create a new gradle project
>>>
>>> 
>>> 
>>>
>>> 3) Go to the "Gradle Tasks" view and run a gradle task (e.g. the
>>>"clean" task)
>>> 
>>>
>>> 4) Close the Eclipse IDE and start it again
>>> 5) The workspace prompt might not be shown any more
>>>
>>> In step 3) the Bundle#start() mehtod is called, which causes OSGi to
>>>corrupt the /configuration/org.eclipse.osgi/framework.info.{x} file
>>>somehow. The problem in the
>>>/configuration/org.eclipse.osgi/framework.info.{x} file then causes
>>>that the workspace prompt is not shown any more.
>>>
>>> We were not able to analyse the concrete failure in
>>>/configuration/org.eclipse.osgi/framework.info.{x}.
>>> But this does not happen always so that might not occur on some
>>>machines. So we guess it might depend on a certain OSGi configuration.
>>> If someone is aware how the
>>>/configuration/org.eclipse.osgi/framework.info.{x} actually works, this
>>>would help a lot.
>>>
>>> For version 1.0.5 of Buildship, I inserted a check, if the UI Plugin,
>>>which is started explicitly by step 3), is already active and also
>>>added the "Bundle.START_TRANSIENT" flag, which was suggested by Thomas
>>>Watson (https://bugs.eclipse.org/bugs/show_bug.cgi?id=478054#c3). The
>>>result of this is that the
>>>/configuration/org.eclipse.osgi/framework.info.{x} stays untouched in
>>>version 1.0.5 of Buildship.
>>>
>>> I think this is also something, which should be fixed directly in the
>>>code, which reads or parses the
>>>/configuration/org.eclipse.osgi/framework.info.{x} file.
>>>
>>> Regards,
>>>
>>> Simon
>>>
>>>
>>> On 23.09.2015 11:16, Etienne Studer wrote:
 This bug only reveals itself under certain conditions (otherwise it
would have been detected/reported a long time ago). Simon was able to
reproduce it. Simon, can you please describe the steps here. Thanks.

 Etienne


 On 23.09.2015, at 11:11, Mickael Istria  wrote:

> On 09/23/2015 11:09 AM, Etienne Studer wrote:
>> Hi Mickael
>>
>> The bug discovered by the user recently has been there for months.
>>It is just that nobody every experienced/reported that bug. Thus,
>>the bug is in all versions of Buildship < 1.0.5.
>> In RC4, we ship Buildship 1.0.3. The fact that the version shows
>>1.0.2.something was a mistake on our side to bump of the version in
>>time for the 1.0.3 release.
> Ok, so we'll need steps to reproduce then. Since taking an EPP Java
>Package (with BuildShip installed) and starting it prompts for
>workspace.
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat
> My blog - My Tweets
> ___
> 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
>>> -- 
>>> Trainer, Consultant and Developer
>>>
>>> vogella GmbH
>>> Haindaalwisch 17a, 22395 Hamburg
>>> Amtsgericht Hamburg: HRB 127058
>>> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
>>> USt-IdNr.: DE284122352
>>> Tel (040) 78804360, Fax (032) 221739404, Email:
>>> simon.sch...@vogella.com, Web: http://www.vogella.com
>>> ___
>>> 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
>>> 

Re: [cross-project-issues-dev] Eclipse Mars 1 RC4 issue with Buildship / workspace prompt

[Doug Schaefer]

OK, I’m awake and have a coffee on the go. As the PMC rep to the planning 
council I’ll be +1’ing the request and passing it along to the planning council 
who are ultimately the ones who decide whether there’s a respin.

But before they do that, I want to make a couple of points and ask for your 
help.

First, we’re having this discussion because we found this issue now and not 
next week. In a sense, we’re lucky we’re in a position to fix this before the 
release. Even if it pushes back the release by a week, which it will.

We need a plan to mitigate these issues no matter when they happen and we 
should have the technology to do it. Projects need the ability to release 
maintenance releases any time and have those releases picked up with an 
Automatic Check for Updates in the EPP packages. We’ve talked about this in the 
Architecture Council and need your help to make sure this works and that the 
projects and packages are structured properly to make sure it works.

BTW, I’m glad the community on cross-projects has spoken on this. It’s great 
input to the planning council who ultimately makes the decision. And that 
decision hasn’t been made yet, so there’s still hope :). We’re a bunch of 
engineers making product decisions, but we’ll try our best.

Doug

From: 
>
 on behalf of Etienne Studer >
Reply-To: Cross project issues 
>
Date: Wednesday, September 23, 2015 at 8:37 AM
To: Cross project issues 
>
Subject: Re: [cross-project-issues-dev] Eclipse Mars 1 RC4 issue with Buildship 
/ workspace prompt

Fyi, in a separate email to the Tools PMC mailing list, I have requested the 
Tools PMC to approve a re-spin of Mars 1 RC4.

Etienne


On 23.09.2015, at 11:55, Marcel Bruch 
> wrote:

Hi Etienne,

Since then, Buildship has been downloaded about 10’000 times but only 2 people 
reported a problem

Well, I think this is not a strong indication for two reasons:

  1.  Eclipse-IDE-wide we see more than half a million submitted (automated) 
error reports in the last quarter - which boil down to twenty-thousand distinct 
problematic locations in source code. Most of them are NullPointerExceptions. 
How many of them have been reported before?
  2.  I also doubt that many users relate the disappearance of the dialog with 
Buildship, thus, rather blame Eclipse than Buildship. It’s a subtile but 
annoying bug.


Besides that:
* I weight the cost of a respin much lower than the annoyance users might 
experience
* I now understand that this issue occurs for Gradle users only (thanks for 
explaining) - but for all of them. As of today 10.000 users got affected by it. 
From October to February (Mars.1) 10.000 * x users will get affected by it 
again. This is a fair amount of users IMHO.
* I assume Buildship would prefer to ship the fixed version (maybe I’m wrong).


So far the discussion has been lead by a handful people - which likely is not 
representative for all opinions.
If I summarize correctly: David is fine with keeping it "as is“, Mikael want’s 
a respin. I second Mikaels position.
Maybe others have no strong feelings or don’t care.

It’s not on me to push a decision. But I’ve a clear preference - pro our users 
and pro Buildship.

Marcel



Am 23.09.2015 um 11:28 schrieb Etienne Studer 
>:

Hi Marcel

Only Buildship users that have launched at least one Gradle task from the Tasks 
View may be affected. And, even then, only two users have reported a problem 
with the workspace prompt so far.

Please note that we introduced the call to bundle.start() on June 6th. Since 
then, Buildship has been downloaded about 10’000 times, but only 2 people 
reported a problem with the workspace prompt (if that serves as any kind of 
indication).

Etienne


On 23.09.2015, at 10:11, Marcel Bruch 
> wrote:

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

My favourite NetBeans troll couldn't miss this opportunity 
https://twitter.com/ehsavoie/status/646583406176960512
Tha and my regular 

Re: [cross-project-issues-dev] New components in Mars.1 (was Re: Eclipse Mars 1 RC4 issue with Buildship / workspace prompt)

[Doug Schaefer]

Ah, that's it. Perfect. Thanks Markus!

IMHO, we should make this mandatory for all packages and have someone just go 
in and do it.

Doug.


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Markus Knauer 
[mkna...@eclipsesource.com]
Sent: Wednesday, September 23, 2015 3:44 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] New components in Mars.1 (was Re: 
Eclipse Mars 1 RC4 issue with Buildship / workspace prompt)

*** Automatically check for updates:

That's enabled in all packages, and all of them are looking for updates of 
their root feature(s) once every week.

*** Package structure:

All Mars packages (with the exception of the RCP/RAP package) are using a 
single root feature that is checked for a higher version. This root feature is 
an EPP feature and controlled by the package maintainers. In theory it could be 
updated and the respective package would be updated with the new content. Of 
course, this works only if the update content is available from one of the p2 
repositories built into the packages (which is the Simultaneous Release p2 
repository).

The RCP/RAP package structure has changed with Mars, as an experiment in order 
to get some experience and as a way to "convince" others in the Neon timeframe 
to change the package structure of the remaining packages. In this package 
*all* content features are installed as root features and therefore checked for 
updates.

Personally I think that's the way to go for all packages. The fact that it is 
enabled in RCP/RAP gives us a chance to get some experience in order to roll it 
out for all packages in the Neon timeframe.

Regards,
Markus


On 23 September 2015 at 21:31, Doug Schaefer 
<dschae...@qnx.com<mailto:dschae...@qnx.com>> wrote:
Step 1 - test to see whether it works. Anecdotal evidence says it doesn't. 
Something about how the EPP packages are defined and built. Also projects need 
to make sure the URLs for maintenance p2 sites are correct and enabled by 
default.

The Check for Updates including the auto check feature itself works. We've used 
it for years in our commercial product. Just need to make sure everything is 
set up correctly for the packages.

I'm also not sure (and actually doubt) auto check is turned on in all the 
packages so that when users start them up and/or on regular intervals it does a 
check and prompts the user to install the updates.

This has to be the default behavior without the user having to do anything. 
That way the user could have installed Mars.1 and then when they start up they 
would have been prompted to install the update for Buildship any other feature 
that happened to have updates out by then.

We talked about this at the architecture call. Not sure it got captured in the 
minutes there. But this is the general idea.

Doug.



From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 
[cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>]
 on behalf of Pascal Rapicault [pas...@rapicorp.com<mailto:pas...@rapicorp.com>]
Sent: Wednesday, September 23, 2015 3:18 PM
To: 
cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] New components in Mars.1 (was Re: 
Eclipse Mars 1 RC4 issue with Buildship / workspace prompt)

I was about to ask the same :)

On 15-09-23 02:54 PM, Mike Milinkovich wrote:
> On 23/09/2015 1:49 PM, Doug Schaefer wrote:
>> if we could ever get Check for Updates working properly, this
>> wouldn't have been such a big issue.
>
> Doug (or anyone)
>
> Is there a written proposal anywhere on how "Check for Updates" should
> be modified?
>
> Is there an existing consensus around such a proposal?
>

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

Re: [cross-project-issues-dev] New components in Mars.1 (was Re: Eclipse Mars 1 RC4 issue with Buildship / workspace prompt)

[Doug Schaefer]

Step 1 - test to see whether it works. Anecdotal evidence says it doesn't. 
Something about how the EPP packages are defined and built. Also projects need 
to make sure the URLs for maintenance p2 sites are correct and enabled by 
default.

The Check for Updates including the auto check feature itself works. We've used 
it for years in our commercial product. Just need to make sure everything is 
set up correctly for the packages.

I'm also not sure (and actually doubt) auto check is turned on in all the 
packages so that when users start them up and/or on regular intervals it does a 
check and prompts the user to install the updates.

This has to be the default behavior without the user having to do anything. 
That way the user could have installed Mars.1 and then when they start up they 
would have been prompted to install the update for Buildship any other feature 
that happened to have updates out by then.

We talked about this at the architecture call. Not sure it got captured in the 
minutes there. But this is the general idea.

Doug.



From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Pascal Rapicault 
[pas...@rapicorp.com]
Sent: Wednesday, September 23, 2015 3:18 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] New components in Mars.1 (was Re: 
Eclipse Mars 1 RC4 issue with Buildship / workspace prompt)

I was about to ask the same :)

On 15-09-23 02:54 PM, Mike Milinkovich wrote:
> On 23/09/2015 1:49 PM, Doug Schaefer wrote:
>> if we could ever get Check for Updates working properly, this
>> wouldn't have been such a big issue.
>
> Doug (or anyone)
>
> Is there a written proposal anywhere on how "Check for Updates" should
> be modified?
>
> Is there an existing consensus around such a proposal?
>

___
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] jetty versions - Another issue to feed on the topic of semantic versioning

[Doug Schaefer]

Can your code not depend on an older version of jetty. Or is only one
version of jetty allowed in a given bundle stack?

Doug.

On 2015-09-16, 4:50 AM, "cross-project-issues-dev-boun...@eclipse.org on
behalf of Max Rydahl Andersen"
 wrote:

>So jetty keeps on giving us some grief now and I think it is worth
>raising this
>since it has some nasty effects.
>
>If I had the option I would wish Jetty was reverted back to .9/.10 in
>Mars.1 until a more permanent/non-breaking option could be found,
>but I assume that is too late. Details below:
>
>The new issue is that to use webSockets from jetty one now need to
>include Apache Aries to make it work.
>
>in 9.2.9 and 9.2.10 this was not necessary, but 9.2.11-13 seem to
>require this.
>
>Now, I know simrel do not include jetty websockets, so it does not
>(currently) affect simrel directly;
>but it for sure affects its adopters.
>
>In short jetty definitely do not retain backwards compatibility between
>its .z releases (9.2.9, 9.2.10 and 9.2.11-13 all behaves differently)
>- https://bugs.eclipse.org/bugs/show_bug.cgi?id=477385
>- https://bugs.eclipse.org/bugs/show_bug.cgi?id=461919#c4
>
>There seem to be no way for us to use jetty inside eclipse and be sure
>the code will work on both Mars.0 and Mars.1.
>
>I know jetty is not directly participating in the simrel train (the
>above is probably part of why ;),
>but I think these latest events raises the issue that simrel should
>not just move up to the latest Jetty version.
>
>The reason we (jboss tools) did not spot this was that the change in
>Mars for jetty was not visible before latest August
>and that was right in the middle of vacation time.
>
>Comments/suggestions/explanations on this would be great!
>
>/max
>
>
>> I don't want to hijack the other thread, but it is related.
>>
>> JBoss Tools noticed that Jetty has some funky API changes going
>> on which unless you are super careful things breaks.
>>
>> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=477385
>>
>> basically jetty 9.2.9, 9.2.10 and 9.2.13 are not compatible
>> with/between each other.
>>
>> Resulting in if platform ships some parts of jetty 9.2.13 and your
>> manifest says it works with 9.2.10 (jetty owns libraries says it does)
>> then things fall apart since you end up with a mix of 9.2.10 and
>> 9.2.13 in your install and that just don't work.
>>
>> Just wondering if others seen this and/or got any tips to better fix
>> this going forward (besides restricting ones version range to 9.2.10
>> and nothing else)
>>
>> /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
>
>
>/max
>http://about.me/maxandersen
>___
>cross-project-issues-dev mailing list
>cross-project-issues-dev@eclipse.org
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Doug Schaefer]

ailto:cross-project-issues-dev-boun...@eclipse.org>
> [mailto:cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>]
>  On Behalf Of Sebastian
> Zarnekow
> Sent: Monday, September 14, 2015 6:24 AM
> To: Cross project issues
> Subject: Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen
> Consequences
>
>
>
>
>
> Hi,
>
>
> I totally second Eds and Eds remarks here. All API policies and all the
> bundle versioning schemes and careful changes in the past would be rendered
> pointless with this move. I doubt that keeping the deprecated interfaces is
> causing effort for the maintainers that is coming even remotely close to the
> pain that clients of existing, potentially broken plugins would suffer from.
>
>
> I strongly recommend to weigh the benefits of removing a few lines of code
> from the repo against the potential harm that this will cause. If and only
> if the deprecated APIs get in the way of successful platform evolution, it
> would seem to be reasonable to discuss a major version increment along with
> the breakage. But even a major increment wouldn't imply that all the
> deprecated code should be blindly removed since deprecated doesn't mean
> something's not working anymore. I'm pretty sure that the backwards
> compatibility is a major success factor for Eclipse as a platform and we
> shouldn't give that away because of an intrinsic motivation to cleanup a few
> lines of code.
>
>
> Best regards,
>
>
> Sebastian
>
>
>
>
>
> On Mon, 14 Sep 2015 at 15:03 Ed Willink < 
> e...@willink.me.uk<mailto:e...@willink.me.uk> > wrote:
>
>
>
>
>
> Hi
>
> This discussion seems to completely ignore:
>
> The major segment number must be increased when a plug-in makes breaking
> changes to its API.
>
> see
> https://wiki.eclipse.org/Version_Numbering#When_to_change_the_major_segment
>
> Deprecation permits breakage but not violation of versioning.
>
> It is certainly very inconvenient to maintain API forever, but arbitrary
> deletion without a consistent version number change is just dishonest; we
> have distributed code that claims to work and it won't.
>
> Perhaps the solution is for the platform to have a major version increase
> every two/three years allowing API clean up. Other projects will be more or
> less forced to synchronize which will be a nuisance, but also a benefit,
> since they too can clean up their APIs.
>
> Let Neon be versioned as 5.0.0 and we can all clean up.
>
> Regards
>
> Ed Willink
>
>
>
>
>
>
> On 14/09/2015 08:31, Ed Merks wrote:
>
>
>
>
> Ian,
>
> That's exactly the key issue that concerns me most. In general I've felt
> uncomfortable with the version ranges for two reasons. Firstly because I
> believe that once set, the lower bound is likely never carefully
> reconsidered as to whether it remains valid. As such, I'm willing to bet
> that a large portion, if not the the vast majority of the bundles, have
> invalid lower bounds. Secondly because the upper bound is a guess; exclusion
> of a major increment is the common best guess. Now it's clear to me that
> even this is generally a bogus guess because any API can become deprecated
> (which is not a problem), but furthermore eventually can be removed, without
> the corresponding major version increment. So older EMF bundles claiming to
> working with any 3.x version of Eclipse will not behave as expected and
> therefore definitely they each have a bogus upper bound. Maybe others are
> comfortable with all this, but personally I am not.
>
> EMF maintains compatibility back to Eclipse 3.6, to make reuse of the latest
> version as flexible as possible for the broadest audience of clients as
> possible. We build against 3.6 and generate version ranges based on what we
> build against (ensuring they aren't bogus). Currently I'm working towards
> EMF 2.12, i.e., 12 years of binary compatibility, and I'm personally not
> comfortable removing public methods, even if they are deprecated, while
> still claiming it's a 2.12 version.
>
> In any case, I was not aware that this was a general policy for the platform.
> Perhaps I'm not the only one. I think deletions ought to be announced, and
> with sufficient advanced waning...
>
> Regardless of how many projects are directly affected, a great many projects
> are indirectly affected when EMF is affected, i.e., notification-based
> updates of viewers will no longer work because of missing class exceptions.
> So a good portion of Neon will simply not function. I wonder when that would
> be (will be) first be noticed?
>
>
>
> On 14/09/2015 6:45 AM, Ian Bull wr

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Doug Schaefer]

This affected CDT too. Luckily we were some what prepared and had one or
our crack committers fix it but it did force us to make a change to
continue on with Neon.

So, I¹m not sure how this is not an API breaking change, deprecated or
not. I believe the Platform is going to have to ask the Planning Council
for an exception for this and get their approval.

Doug.

On 2015-09-12, 4:32 AM, "cross-project-issues-dev-boun...@eclipse.org on
behalf of Ed Willink"  wrote:

>Hi
>
>TableTreeViewer removal was announced in
>
>http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.i
>sv%2Fporting%2Fremovals.html
>
>But IPlatformRunnable is only announced as after June 2017 in
>
>http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.i
>sv%2Fporting%2Fremovals.html
>
>so the discussed removal in
>
>https://bugs.eclipse.org/bugs/show_bug.cgi?id=475944
>
>seems premature.
>
> Regards
>
> Ed Willink
>
>On 12/09/2015 09:05, Ed Merks wrote:
>> Hi,
>>
>> It was brought to my attention that
>> org.eclipse.jface.viewers.TableTreeViewer has been deleted.  Yes, I
>> know it's deprecated, but nevertheless it was once API before being
>> deprecated so deleting it is a breaking change.  I don't recall there
>> being an announcement to begin deleting arbitrary deprecated API.
>>
>> In any case, I can't necessarily commit to making the necessary
>> changes.  As such I can't commit to contributing EMF Core to Neon.
>>
>> I would suggest reconsidering the strategy of breaking APIs and most
>> certainly suggest any such actions ought to be announced and discussed
>> before such actions are taken.
>>
>> Regards,
>> 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
>>
>>
>> -
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2015.0.6125 / Virus Database: 4419/10626 - Release Date:
>> 09/12/15
>>
>>
>
>___
>cross-project-issues-dev mailing list
>cross-project-issues-dev@eclipse.org
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [aeri] Skipping UI freeze reports caused by OSGI class loading for Mars.1?

[Doug Schaefer]

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.

Doug.


On 2015-08-25, 1:57 AM, cross-project-issues-dev-boun...@eclipse.org on
behalf of Marcel Bruch cross-project-issues-dev-boun...@eclipse.org on
behalf of marcel.br...@codetrails.com wrote:

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/55dabf6
ae4b0f0b83a6ed605/details
[2] 
https://dev.eclipse.org/recommenders/committers/confess/#/problems/55d8009
8e4b0f0b83a6eae77/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

___
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] CDT in Neon (was: Are *you* ready for M4?)

[Doug Schaefer]

:), Thanks, Marc. I was going to send one and sign it Caption Obvious. ;).

It is important though to let everyone know the CDT is going to have a major 
release in Neon. Not sure how much API is going to change, maybe none if it, 
but we've opened the door to clean up a few things.

Doug.

From: Marc Khouzam marc.khou...@ericsson.commailto:marc.khou...@ericsson.com
Date: Thu Aug 20 2015 16:07:27 GMT-0400 (EDT)
To: cross-project-issues-dev@eclipse.org 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] CDT in Neon (was: Are *you* ready for M4?)

I'm not sure if Doug's email below is enough, so, to be safe, CDT will be part 
of Neon with a 9.0 release with offset +1.

Marc

On Thu, Dec 4, 2014 at 6:11 PM, Doug Schaefer 
dschae...@qnx.commailto:dschae...@qnx.com wrote:

CDT will be in every simultaneous release from the first one until forever.

Doug.


___
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] PTP hudson page

[Doug Schaefer]

You should raise a bug on that, not sure Denis and gang are watching this list.

Sent from my BlackBerry 10 smartphone on the Rogers network.
  Original Message
From: Greg Watson
Sent: Tuesday, May 26, 2015 5:42 PM
To: Cross project issues
Reply To: Cross project issues
Subject: [cross-project-issues-dev] PTP hudson page


Anyone know why the PTP [1] hudson page is showing a “Hudson CI Server Initial 
Setup” screen? Has someone changed something?

Greg

1. https://hudson.eclipse.org/ptp/
___
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] Documentation and signing requirements for Mars

[Doug Schaefer]

BTW, the new launch bar feature isn’t signed yet. I’ll work on that today.

Doug.

From: Wayne Beaton wa...@eclipse.orgmailto:wa...@eclipse.org
Organization: The Eclipse Foundation
Reply-To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date: Tuesday, May 5, 2015 at 11:44 AM
To: 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Documentation and signing requirements 
for Mars

Many of the entries on the unsigned report [1] are features.

Features must also be signed.

Please check if your features are on the list. Note that the report doesn't 
include a path or make any particular distinction for features. I chased a 
plug-in for a solid hour yesterday before I noticed that there was a feature 
with exactly the same id (but with a different version number).

David, perhaps some future version of the tool can include more of the file 
path or some indication of feature vs. plug-in.

Wayne

[1] 
https://hudson.eclipse.org/simrel/job/simrel.mars.runaggregator.CLEAN_BUILD/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/reports/verifydiroutput/unsigned8.txt

On 29/04/15 04:40 PM, Wayne Beaton wrote:
READ THIS AND TAKE ACTION IF YOU ARE PARTICIPATING IN THE MARS SIMULTANEOUS 
RELEASE.

It looks like a few features aren't implementing the rules of participation 
[1]. If your project does not conform to the rules, it will fail the release 
review. If it does not make sense for your project to conform to the 
documentation and signing requirements, I will expect this to be documented in 
the release review materials and explicitly approved by your PMC.

Frankly, I'm primarily concerned with making sure that the legal documentation 
requirements are met and that the user experience has the fewest number of 
surprises.

To that end, please look at these reports. Focus on the Bundles missing 
required files, Unsigned JARs, Feature Copyrights, and Consistent, 
current licenses (SUA) in features links. Resolve these first and then look at 
the rest of entries to make sure that you're getting them right as well.

I feel very strongly that every feature should have a description that's better 
than My feature. Describe the feature with one or two sentences.

David, feel free to add your concerns to this list.

I've got some bugs open on some SUA problems. If I've opened a bug against your 
project, please deal with it ASAP.

Upcoming dates reminder:

May 22/2015 - IP Log submission deadline
May 29/2015 - Review materials due
June 12/2015 - Release Review

Thanks,

Wayne

[1] 
https://hudson.eclipse.org/simrel/job/simrel.mars.runaggregator.CLEAN_BUILD/60/artifact/aggregation/final/buildInfo/reporeports/index.html
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseCon France 2015]http://www.eclipsecon.org/france2015



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.orgmailto: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

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseConFrance 2015]http://www.eclipsecon.org/france2015
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
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] Unable to contribute to Mars... very frustrated

[Doug Schaefer]

Yeah, that caught me for a while the first time too.

If you push directly to the master branch, it goes straight in without going 
through the Gerrit review part. In that case Gerrit is just an over-engineered 
git server.

You only see it in Gerrit if you push to gerrit, I.e. refs/for/master, in which 
case, it’ll show up in your list of Changes on gerrit.eclipse.org.

Doug.

From: Konstantin Komissarchik 
konstantin.komissarc...@oracle.commailto:konstantin.komissarc...@oracle.com
Reply-To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date: Tuesday, May 5, 2015 at 4:21 PM
To: 'Cross project issues' 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Unable to contribute to Mars... very 
frustrated

Thanks, Doug! The “save private key” button was the magic step that I was 
missing.

Now I am able to fetch the repo and push my change, but I am not done yet, am 
I? I need to go somewhere to monitor and approve it now?

- Konstantin


From: 
cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug 
Schaefer
Sent: Tuesday, May 05, 2015 1:08 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Unable to contribute to Mars... very 
frustrated

Yeah, the key on Windows is to make sure the SSH2 home on the General tab 
points to some where useful, like C:\Users\dschaefer\.ssh, and that you click 
the Save Private Key button to save it there.

From: Mickael Istria mist...@redhat.commailto:mist...@redhat.com
Reply-To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date: Tuesday, May 5, 2015 at 4:00 PM
To: 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Unable to contribute to Mars... very 
frustrated

On 05/05/2015 09:48 PM, Konstantin Komissarchik wrote:
 Have you uploaded your SSH key to Gerrit ? 
 https://wiki.eclipse.org/Gerrit#SSH_Keys

It would require having such a key in the first place. I understand the theory 
of it and I’ve seen tools to gen key pairs, but I don’t know where I am 
supposed to stash the private key, for instance so that it will hookup with the 
public key on Gerrit.
If you have your keys generated with openssh, they are put in the regular 
~/.ssh folder, which Eclipse and EGit will use. So just generating the keys 
should be enough.


 Did you try to use HTTPS instead ? 
 https://wiki.eclipse.org/Gerrit#Git_over_HTTPS

Yep. Tried this URL:
https://kkomissarc...@git.eclipse.org/r/p/simrel/org.eclipse.simrel.build.git
Getting “not authorized” when trying to push.
Ok, that's not a very helpful error message.
Is this URL the same as the one you see in 
https://git.eclipse.org/r/#/admin/projects/simrel/org.eclipse.simrel.build when 
selecting HTTP ?  Gerrit had an issue with some users in the past, creating 
different Gerrit users for the same account.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hathttp://www.jboss.org/tools
My bloghttp://mickaelistria.wordpress.com - My 
Tweetshttp://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

Re: [cross-project-issues-dev] Unable to contribute to Mars... very frustrated

[Doug Schaefer]

Use the Gerrit workflow. The Hudson job watches Gerrit for change requests and 
fires off a job when it sees one.

From: Konstantin Komissarchik 
konstantin.komissarc...@oracle.commailto:konstantin.komissarc...@oracle.com
Reply-To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date: Tuesday, May 5, 2015 at 4:26 PM
To: 'Cross project issues' 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Unable to contribute to Mars... very 
frustrated

Yep. Just figured out that it went directly in. Oy!

So what should I have done if I wanted to exercise the new verifier feature?

- Konstantin


From: 
cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mickael 
Istria
Sent: Tuesday, May 05, 2015 1:24 PM
To: 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Unable to contribute to Mars... very 
frustrated

On 05/05/2015 10:21 PM, Konstantin Komissarchik wrote:
Thanks, Doug! The “save private key” button was the magic step that I was 
missing.

Now I am able to fetch the repo and push my change, but I am not done yet, am 
I? I need to go somewhere to monitor and approve it now?
Nope. it's in: 
http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=718277402528603ca8c2522b5c05180e3d64f215

I'll add a note in the paragraph 
https://wiki.eclipse.org/index.php?title=Simrel/Contributing_to_Simrel_Aggregation_Build#As_a_SimRel_committer.2C_push_directly_to_the_target_branch
 to make clear that this workflow doesn't trigger a Gerrit review.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hathttp://www.jboss.org/tools
My bloghttp://mickaelistria.wordpress.com - My 
Tweetshttp://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

Re: [cross-project-issues-dev] jdt.core move to Java 7 BREE

[Doug Schaefer]

Our consensus has always been to not have a consensus. Each project moved to 
where they needed to be when they needed to be. Obviously the decisions of 
other projects affect yours, particularly the platform. And for that, I go by 
their project plan which has no mention of JRE 6 for Mars.

https://www.eclipse.org/projects/project-plan.php?planurl=/eclipse/development/plans/eclipse_project_plan_4_5.xml

Doug.

From: Ed Willink e...@willink.me.ukmailto:e...@willink.me.uk
Reply-To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date: Wednesday, March 4, 2015 at 11:46 AM
To: 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] jdt.core move to Java 7 BREE

Hi

(I would love it if Mars required Java 8, since I like @NonNull annotations and 
the Java 7 compatibility is really troublesome.)

However I am keen that my project follows the Eclipse consensus, which does not 
seem to exist. My Hudson builds now fail so I need to know where the new 
consensus is.

Regards

Ed Willink

On 04/03/2015 16:32, Konstantin Komissarchik wrote:
What is the rationale for wanting to keep BREE levels as low as possible? Even 
Java 7 enters the “no further public updates” phase in April of this year. JRE 
7 users in the normal update pipeline were upgraded to Java 8 in January. Are 
there really users out there who _cannot_ run a newer version of the JRE 
despite security and performance implications of running an old version? I am 
guessing that if Mars were to require Java 8, there would be some initial 
grumbling over having to upgrade, then everyone moves on in a better and more 
secure configuration.

http://www.oracle.com/technetwork/java/javase/downloads/eol-135779.html

Thanks,

- Konstantin


From: 
cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ed Willink
Sent: Wednesday, March 04, 2015 6:57 AM
To: 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] jdt.core move to Java 7 BREE

Hi

But this is important.

When osgi.utils moved from Java 5 to Java 6 that made Eclipse almost unuseable 
as a Java 5 platform; not really a problem.

Now jdt.core does nearly the same thing for Eclipse as a Java 6 platform. Are 
we ready to go that far? IMHO it certainly should be discussed and announced.

Regards

Ed Willink
On 04/03/2015 14:42, Daniel Megert wrote:
Hi Ed

Yes, this was intended. We never announce BREE changes.

Dani



From:Ed Willink e...@willink.me.ukmailto:e...@willink.me.uk
To:Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date:04.03.2015 15:27
Subject:[cross-project-issues-dev] jdt.core move to Java 7 BREE
Sent by:
cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org




Hi

Is the recent change in BREE for org.eclipse.jdt.core from Java 6 to
Java 7 intended?

Was it announced?

Regards

Ed Willink
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.orgmailto: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.orgmailto: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.comhttp://www.avg.com
Version: 2015.0.5751 / Virus Database: 4299/9224 - Release Date: 03/04/15




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.orgmailto: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.comhttp://www.avg.com
Version: 2015.0.5751 / Virus Database: 4299/9224 - Release Date: 03/04/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

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

[Doug Schaefer]

Ideally, we have a product/project manager who puts all this together. Don’t 
let engineers do your marketing :).

D

From: Wayne Beaton wa...@eclipse.orgmailto:wa...@eclipse.org
Organization: The Eclipse Foundation
Reply-To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date: Monday, February 2, 2015 at 10:53 AM
To: 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Joint NN page for the release train

Okay. Avoidance of more work is a requirement. Forget all that silliness about 
a common XML file format and putting extra files in features.

Wayne

On 02/02/15 10:03 AM, Daniel Megert wrote:
For us it would mean more work, which I'd like to avoid. Having one document 
easily allows to tools to e.g. check for XHTML validity, and help fix such 
issues. If the document is generated out of pieces, then it can be a tedious 
task to get to a generated document that is valid. The extension point doc is 
such an example: the text for the elements is entered in the extension point 
editor in separate fields, and during build a document is generated. If there 
are errors, it's hard to detect and fix them. Also, spell checking a single 
document is easier than doing the same over different fragments.

Another point is, that the NN of a release is not simply the collection of the 
milestone NNs. We e.g. put the new Quick Fixes under one item for the release, 
or a feature that got developed over several milestones with entries in the 
corresponding milestone NNs will have to be collapsed into a single entry.

I'd like to keep our approach for our project, since it works well for us, and 
produces good quality NN documents. If other projects want to try out 
something new where the NN is generated, and provide feedback about how it 
worked for them, that's of course fine for me too.

Dani

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseCon2015]http://www.eclipsecon.org/na2015
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
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

[Doug Schaefer]

From: Lars Vogel lars.vo...@vogella.commailto:lars.vo...@vogella.com
 Ideally, we have a product/project manager who puts all this together. Don’t 
 let engineers do your marketing :).

-1, having worked for a large software company in the past, I think the current 
platform approach of having the developer describe his development is much more 
efficient.

Efficient, yes. But effective at producing content that users/customers may be 
interested in and help sell them on your product without getting lost in the 
tragedy of the commons? To be honest, I think a NN for the entire release 
train that isn’t managed by a single person will be a disaster.



On Mon, Feb 2, 2015 at 6:04 PM, Doug Schaefer 
dschae...@qnx.commailto:dschae...@qnx.com wrote:
Ideally, we have a product/project manager who puts all this together. Don’t 
let engineers do your marketing :).

D

From: Wayne Beaton wa...@eclipse.orgmailto:wa...@eclipse.org
Organization: The Eclipse Foundation
Reply-To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date: Monday, February 2, 2015 at 10:53 AM
To: 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Joint NN page for the release train

Okay. Avoidance of more work is a requirement. Forget all that silliness about 
a common XML file format and putting extra files in features.

Wayne

On 02/02/15 10:03 AM, Daniel Megert wrote:
For us it would mean more work, which I'd like to avoid. Having one document 
easily allows to tools to e.g. check for XHTML validity, and help fix such 
issues. If the document is generated out of pieces, then it can be a tedious 
task to get to a generated document that is valid. The extension point doc is 
such an example: the text for the elements is entered in the extension point 
editor in separate fields, and during build a document is generated. If there 
are errors, it's hard to detect and fix them. Also, spell checking a single 
document is easier than doing the same over different fragments.

Another point is, that the NN of a release is not simply the collection of the 
milestone NNs. We e.g. put the new Quick Fixes under one item for the release, 
or a feature that got developed over several milestones with entries in the 
corresponding milestone NNs will have to be collapsed into a single entry.

I'd like to keep our approach for our project, since it works well for us, and 
produces good quality NN documents. If other projects want to try out 
something new where the NN is generated, and provide feedback about how it 
worked for them, that's of course fine for me too.

Dani

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseCon2015]http://www.eclipsecon.org/na2015
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.orgmailto: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



--
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.commailto:lars.vo...@vogella.com, Web: 
http://www.vogella.com
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve

Re: [cross-project-issues-dev] Hudson fails to access http://download.eclipse.org/eclipse/updates/4.4-M-builds

[Doug Schaefer]

No, I think they're all broken. One I was using can't see the git repos.

Sent from my BlackBerry 10 smartphone on the Rogers network.
From: Marcel Bruch
Sent: Saturday, January 31, 2015 1:28 PM
To: Cross project issues
Reply To: Cross project issues
Subject: [cross-project-issues-dev] Hudson fails to access 
http://download.eclipse.org/eclipse/updates/4.4-M-builds



Our HIPP builds got stuck on accessing the p2 update site from 
download.eclipse.orghttp://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.orghttp://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


[WARNING] Failed to access p2 repository 
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.


[WARNING] Failed to access p2 repository 
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.


[WARNING] Failed to access p2 repository 
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.


___
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] Patch updates, reboot

[Doug Schaefer]

Ah, that's what's happening. Thanks Denis!

Sent from my BlackBerry 10 smartphone on the Rogers network.
  Original Message
From: Denis Roy
Sent: Tuesday, January 27, 2015 8:17 PM
To: Cross project issues
Reply To: Cross project issues
Subject: [cross-project-issues-dev] Patch updates, reboot


Greetings,

You may notice some glitches in the build servers and HIPP -- we're
applying some critical OS updates and need to restart them all. We'll
have everything purring along in no time.

Thanks for your understanding.

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
___
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] Webtools JSDT considering new Bower integration

[Doug Schaefer]

Same with CDT. In fact we have a lot of floating parts that we depend on and 
depend on us, almost cyclical. It's only an issue when APIs change and we just 
manage those cases carefully.

But with the size of they simrel, the offset model is out dated, especially if 
the number is days.

Sent from my BlackBerry 10 smartphone on the Rogers network.
From: Ed Willink
Sent: Thursday, January 8, 2015 4:47 PM
To: cross-project-issues-dev@eclipse.org
Reply To: Cross project issues
Subject: Re: [cross-project-issues-dev] Webtools JSDT considering new Bower 
integration


Hi

OCL is at +1 but depends on Xtext at +2.

We build at +1 against the latest Xtext I-build incurring a risk that we might 
have to rebuild again at +2/+3. Hopefully such a rebuild would fix only trivial 
problems.

We have been doing this for over a year and recall only one problem that was 
stressful given the short timescales but not that hard.

The risk is much reduced if your dependents provide I/N-builds regularly and do 
not make last minute API changes. This is necessary anyway since if you do not 
monitor your dependents until you do your final build you give them only hours 
to respond to the bugs that you reveal; no chance; you have to fudge a 
workaround. With regular latest state builds you can often report bugs within a 
week giving plenty of time for retraction/resolution.

If your build options are correct a rebuild can produce the identical 
deliverables making the rebuild test easy. We had to eliminate obsolete 
practices such as mapping.ini in which the build time was incorporated into 
source and so guaranteed a pseudo-change.

 Regards

Ed Willink

On 08/01/2015 20:40, Chuck Bridgham wrote:
I'm posting this to cross-projects because we are considering a change that 
requires a significant dependency (jGit).
A new contribution to JSDT revolves around support for Bower javascript package 
manager runtime, and this has a jGit dependency.
Our biggest issue from a build standpoint is we (WTP) have a +2 offset, while 
jGit is +3.  I'm actually surprised this has remained at +3.

I'm looking for advise how to proceed, what options do we have to consider this 
change?  Ask for jGit to move to +2?  Change the packaging
of the JSDT bower support to be optional?  What have other projects done in 
this case?


Thanks - Chuck

Senior Architect, WebSphere Developer Tools, Eclipse WTP PMC Lead
IBM Software Lab - Research Triangle Park, NC


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.orgmailto: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.comhttp://www.avg.com
Version: 2015.0.5577 / Virus Database: 4257/8893 - Release Date: 01/08/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

Re: [cross-project-issues-dev] Projects missing from Mars

[Doug Schaefer]

I'm working with Greg Watson and the TM, PTP, and CDT teams to come up with a 
new target management system based on org.eclipse.remote. All signs point to 
that being available for Mars. Coding is underway but I'm just not ready to 
commit at this time. Let's see what January brings.

Doug

Sent from my BlackBerry 10 smartphone on the Rogers network.
From: Wayne Beaton
Sent: Thursday, December 11, 2014 2:29 PM
To: Cross project issues
Reply To: Cross project issues
Subject: [cross-project-issues-dev] Projects missing from Mars


Greetings folks.

I believe that I'm caught up with the opt-in.

The following projects are on the dropped list:

  *   Intent
  *   Target Management
  *   Data Tools Platform
  *   Java Workflow Tooling
  *   Marketplace Client
  *   Koneki
  *   Target Communication Framework

Both Intent and Target Management have informed the community that they've 
dropped out (though there is still some ongoing discussion regarding TM).

The rest have not yet created a release record. I'm expecting that least two of 
them (Data Tools and Marketplace Client) really do want to participate. I'll 
give them all a kick.

Wayne
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseCon2015]http://www.eclipsecon.org/na2015
___
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] Projects missing from Mars

[Doug Schaefer]

BTW, I am going to take another look at the TM Terminal. Dropping should be 
considered on hold at the moment. It might have a place with our o.e.remote 
strategy and has some UX features that are actually better than the TCF 
Terminal, like multiple views. Again no commitments but I should have a good 
understanding of where we need this to go by end of Jan.

BTW2, my biggest problem is that I’m releasing the LaunchBar in Luna SR-2 with 
CDT 8.6 and it has dependencies on all this stuff. So I’m walking a bit of a 
tight rope on this at the moment.

Doug.

From: Oberhuber, Martin 
martin.oberhu...@windriver.commailto:martin.oberhu...@windriver.com
Reply-To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date: Thursday, December 11, 2014 at 2:55 PM
To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Projects missing from Mars

Hi Wayne, all –

Target Communication Framework (TCF) intends to participate in Mars with an 1.3 
release
(or probably 1.4 in case we end up releasing 1.3 sooner – at any rate it’ll be 
backward compatible).

Key things we’re working on include

-  Improve the TCF Terminals View and have it picked up as the default 
terminal by EPP packages (instead of TM Terminal which drops from Mars)

-  Symbol resolver improvements for C++11 and ADA Debugging

-  Improve documentation for new adopters and extenders of TCF

Our release record is here:
https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.3.0

Our offset will be +2 (since we depend on CDT)

And I couldn’t figure out where to “flip the flag” on the PMI to show Mars 
participation, so please let me know if anything is still missing.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: 
cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Wayne Beaton
Sent: Thursday, December 11, 2014 8:29 PM
To: Cross project issues
Subject: [cross-project-issues-dev] Projects missing from Mars

Greetings folks.

I believe that I'm caught up with the opt-in.

The following projects are on the dropped list:
· Intent
· Target Management
· Data Tools Platform
· Java Workflow Tooling
· Marketplace Client
· Koneki
· Target Communication Framework

Both Intent and Target Management have informed the community that they've 
dropped out (though there is still some ongoing discussion regarding TM).

The rest have not yet created a release record. I'm expecting that least two of 
them (Data Tools and Marketplace Client) really do want to participate. I'll 
give them all a kick.

Wayne
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseCon2015]http://www.eclipsecon.org/na2015
___
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] Projects missing from Mars

[Doug Schaefer]

No need to be violent :). This came out of a conversation with Greg, the TM 
project lead. We’re just questioning finally what TCF is trying to do with the 
terminal, why it couldn’t be done in it’s proper home in tm-dev, and why it has 
to be so different. This has been part of my out-reach out to the projects to 
make sure we have a target management system that meets all our needs. I need 
to do some digging to understand more. We can discuss more on the tm-dev list.

Doug.

From: Oberhuber, Martin 
martin.oberhu...@windriver.commailto:martin.oberhu...@windriver.com
Reply-To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date: Thursday, December 11, 2014 at 3:07 PM
To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Projects missing from Mars

Doug,

As a committer on TM and a project lead on TCF I am violently opposed against 
keeping the TM terminal alive.

If you still believe that TCF terminal does not support multiple views, you are 
1.5 years or more late with your assessment.

As of today, the TCF Terminals view is at 100% feature parity compared to TM 
Terminal, and offers MUCH more (like drag-and-drop rearrangement of its 
multiple views for example, local terminal support, proper detection of target 
encoding and more). I’ve documented the feature parity on a bugzilla bug long 
ago if you want details (just don’t have time digging that out now).

Please, don’t make announcements like this without talking to the committers on 
the projects that you are talking about.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: 
cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug 
Schaefer
Sent: Thursday, December 11, 2014 9:03 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Projects missing from Mars

BTW, I am going to take another look at the TM Terminal. Dropping should be 
considered on hold at the moment. It might have a place with our o.e.remote 
strategy and has some UX features that are actually better than the TCF 
Terminal, like multiple views. Again no commitments but I should have a good 
understanding of where we need this to go by end of Jan.

BTW2, my biggest problem is that I’m releasing the LaunchBar in Luna SR-2 with 
CDT 8.6 and it has dependencies on all this stuff. So I’m walking a bit of a 
tight rope on this at the moment.

Doug.

From: Oberhuber, Martin 
martin.oberhu...@windriver.commailto:martin.oberhu...@windriver.com
Reply-To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date: Thursday, December 11, 2014 at 2:55 PM
To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Projects missing from Mars

Hi Wayne, all –

Target Communication Framework (TCF) intends to participate in Mars with an 1.3 
release
(or probably 1.4 in case we end up releasing 1.3 sooner – at any rate it’ll be 
backward compatible).

Key things we’re working on include

-  Improve the TCF Terminals View and have it picked up as the default 
terminal by EPP packages (instead of TM Terminal which drops from Mars)

-  Symbol resolver improvements for C++11 and ADA Debugging

-  Improve documentation for new adopters and extenders of TCF

Our release record is here:
https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.3.0

Our offset will be +2 (since we depend on CDT)

And I couldn’t figure out where to “flip the flag” on the PMI to show Mars 
participation, so please let me know if anything is still missing.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From:cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Wayne Beaton
Sent: Thursday, December 11, 2014 8:29 PM
To: Cross project issues
Subject: [cross-project-issues-dev] Projects missing from Mars

Greetings folks.

I believe that I'm caught up with the opt-in.

The following projects are on the dropped list:
? Intent
? Target Management
? Data Tools Platform
? Java Workflow Tooling
? Marketplace Client
? Koneki
? Target Communication Framework

Both Intent and Target Management have informed the community that they've 
dropped out (though there is still some ongoing discussion regarding TM).

The rest have not yet created a release record. I'm expecting that least two of 
them (Data Tools and Marketplace Client) really do want to participate. I'll

Re: [cross-project-issues-dev] Are *you* ready for M4?

[Doug Schaefer]

Also, that I can’t explicitly state it right now anyway. And those that need to 
know need to follow the cdt-dev list to be involved in the discussion.

From: Wayne Beaton wa...@eclipse.orgmailto:wa...@eclipse.org
Organization: The Eclipse Foundation
Reply-To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date: Thursday, December 4, 2014 at 1:48 PM
To: 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Are *you* ready for M4?

So what you're saying is that there really is no way that I could know what you 
mean without you explicitly stating it? ;-)

Wayne

On 04/12/14 01:41 PM, Doug Schaefer wrote:
We actually haven’t decided whether to do 8.7 or 9.0. We’ll decide that after 
we get 8.6 out for Luna SR-2. And the dependency tree is getting pretty complex 
to say we’re +1. But we’ve figured out how to manage that.

Doug.

From: Wayne Beaton wa...@eclipse.orgmailto:wa...@eclipse.org
Organization: The Eclipse Foundation
Reply-To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date: Thursday, December 4, 2014 at 12:55 PM
To: 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Are *you* ready for M4?

I've added CDT 8.7 as a +1 participant.

Wayne

On 04/12/14 11:11 AM, Doug Schaefer wrote:
CDT will be in every simultaneous release from the first one until forever.

Doug.

From: Wayne Beaton wa...@eclipse.orgmailto:wa...@eclipse.org
Organization: The Eclipse Foundation
Reply-To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date: Wednesday, December 3, 2014 at 11:14 PM
To: 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Are *you* ready for M4?

I am a little backlogged with my email, so I may not have added your record 
yet. I'll try to push through all the Mars participation notes by the end of 
the week (and will take a quick look through the archive to see if I've missed 
anybody).

Wayne

On 03/12/14 09:05 PM, David M Williams wrote:
there are 21 projects that have dropped out of Mars! (That list is about half 
way down the left-most column.)   I am pretty sure some of them do not intend 
to drop out (such as CDT! WTP! Xpand!? Mylyn! ... ) and I am moderately sure 
some of those have declared intent on this list, so I am wondering if there is 
a problem with your release record ... or something?  In any case, please 
work with Wayne if something is amiss or missed.

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseCon 2015]http://www.eclipsecon.org/na2015



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.orgmailto: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

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseCon 2015]http://www.eclipsecon.org/na2015



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.orgmailto: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

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseCon2015]http://www.eclipsecon.org/na2015
___
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] TM withdrawal from Mars

[Doug Schaefer]

The fact of the matter is that RSE is an architectural nightmare. It has a 
history as a remote environment for IBM mainframes which was super overkill for 
what we use it for in the Linux and embedded space. Good riddance IMHO.

To that end, I am currently working on removing our dependency on RSE in CDT 
and will be using the org.eclipse.remote plug-ins started by the Parallel Tools 
folks. It’s a much simpler architecture and super easy to extend. It already 
has support for ssh connections.

Doug.

From: Wayne Beaton wa...@eclipse.orgmailto:wa...@eclipse.org
Organization: The Eclipse Foundation
Reply-To: Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date: Friday, November 21, 2014 at 2:51 PM
To: 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] TM withdrawal from Mars

I had a similar thought. I actually use RSE. In fact, I just did a bunch of 
work to include an adapter for my image viewer plug-in to preview images via 
RSE (I'll share this shortly).

There's no requirement for a project to make new releases for the simultaneous 
release. There's nothing stopping a project from just contributing a service 
release.

I should think that most of the heavy lifting is done. It's perfectly 
reasonable for a project to remain in maintenance mode.

What additional resources to you believe that you require? I believe that all 
you need to do is declare your participation and make sure that the aggregation 
file is correct. Perhaps others can help with this.

Wayne

On 21/11/14 02:41 PM, Max Rydahl Andersen wrote:

That sounds really bad :/
This means if I grok it right that eclipse will loose its ability to mount and 
browse Ftp and scp files systems, correct ?

If that goes eclipse becomes really weak in the already remote heavy access 
world with cloud and containers.

For one our server adapters utilizes this to support remote deployment to file 
based servers.

What would it take for keeping rse or at least parts of it alive for mars and 
future releases ?

/max
http://about.me/maxandersen

On 21 Nov 2014, at 17:25, Greg Watson 
g.wat...@computer.orgmailto:g.wat...@computer.org wrote:

The Target Management (TM) project is comprised of two main projects: Remote 
System Explorer (RSE) and Terminal. Only the Terminal project is under active 
development, and there are plans currently to merge this with the TCF Terminal 
project. We are planning to have one final release of TM (3.7) to coincide with 
Luna SR2, and then only provide service releases on an as-needed basis. As a 
consequence, we don’t have the resources to contribute to a Mars release, so 
are notifying everyone of our intention to withdraw from Mars.

Please let us know if there are any comments or concerns regarding this.

Regards,
Greg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.orgmailto: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.orgmailto: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

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseCon2015]http://www.eclipsecon.org/na2015
___
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] Limiting GTK versions supported by SWT or SWT call for help

[Doug Schaefer]

+1 for dropping GTK3 and staying on 2. I'd like to jump on to JavaFX/SWT as 
soon as they fix some bugs in the web view.

Sorry I missed the earlier note on Qt as well. Something I've been thinking 
about again as I start working with it more and more in the C++ space.

Doug.

From: Tom Schindl 
tom.schi...@bestsolution.atmailto:tom.schi...@bestsolution.at
Date: Wed Oct 08 2014 18:16:56 GMT-0400 (EDT)
To: cross-project-issues-dev@eclipse.org 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Limiting GTK versions supported by SWT 
or SWT call for help

hi,

dropping Gtk2 means:
* swing embed is broken when the Gtk-Theme is used because it links
against Gtk2
* javafx embed is broken because it links against Gtk2

So clearly openjdk/oraclejdk (even the latest builds) links against
Gtk2, or am I wrong in this regard?

I can also prove what Andrey said: We have turned of Gtk3 on *all* our linux 
desktops because there are too many problems with it.

Tom

On 08.10.14 16:18, Aleksandar Kurtakov wrote:
 - Original Message -
 From: Andrey Loskutov losku...@gmx.demailto:losku...@gmx.de
 To: Cross project issues 
 cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org,
  Aleksandar Kurtakov akurt...@redhat.commailto:akurt...@redhat.com  
 Sent: Wednesday, October 8, 2014 5:11:53 PM
 Subject: Re: [cross-project-issues-dev] Limiting GTK versions supported by 
 SWT or SWT call for help 
 BTW we at Advantest are still using RHEL 5.8, even because RHEL has crazy  
 long support times :o)

 Limiting to GTK3 only and drop GTK2 ports for *new* Eclipse releases would 
 be  good idea but AFAK GTK3 SWT port is still problematic (I'm on *latest* 
  Ubuntu and must turn it off).

 In general I would also prefer to have always *one* (smallest possible from 
  latest GTK on major distros) SWT port for latest Eclipse release but that 
  port must be 99% usable.

 I won't hijack the thread, but the best long term solution for SWT Linux  
 ports and Eclipse UI toolkit in general would be to move away from SWT to  
 Java FX or better Qt (I know Qt LGPL license is a showstopper, but this *is* 
  technically viable alternative). Without the man power of IBM (which  
 originally allowed SWT to be developped for so many different plattforms)  
 SWT as we have it today has no feature.

 Options are endless. But let's try to limit the discussion towards Mars and 
 Mars+1 for now. In this timeframe I don't think a new option will pop up and 
 I'm trying to solve our daily issues first so we can try to look a bit 
 further. 

 Alexander Kurtakov
 Red Hat Eclipse team



 Am 8. Oktober 2014 16:44:30 OESZ, schrieb Aleksandar Kurtakov
 akurt...@redhat.commailto:akurt...@redhat.com:
 - Original Message -
 From: Mat Booth mat.bo...@redhat.commailto:mat.bo...@redhat.com
 To: Cross project issues 
 cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
   Sent: Wednesday, October 8, 2014 4:27:25 PM
 Subject: Re: [cross-project-issues-dev] Limiting GTK versions
 supported by SWT or SWT call for help

 - Original Message -
 From: Igor Fedorenko i...@ifedorenko.commailto:i...@ifedorenko.com
 To: 
 cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
 Sent: Wednesday, 8 October, 2014 12:38:10 PM
 Subject: Re: [cross-project-issues-dev] Limiting GTK versions
 supported by
 SWT or SWT call for help

 What major distribution still stuck with GTK2? Aren't they all on  GTK3
 already?

 --
 Regards,
 Igor


 RHEL 6/CentOS 6 only has GTK 2.20, IIRC


 --
 Kind regards,
 Andrey Loskutov

 http://google.com/+AndreyLoskutov

 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.orgmailto: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.orgmailto: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] e(fx)clipse participating in Mars release

[Doug Schaefer]

I guess this raises another question. What about the other way. e(fx)clipse 
doesn't get in the way, but does it help either? i.e. With e(fx)clipse on the 
release train, would it be possible to have an Eclipse EPP package use JavaFX?

All the magic required to get this actually running really confirms what many 
people are telling me, that JavaFX is ready for prime time. I love the 
direction, but there are a lot of hurdles to actually use it in product. In our 
testing at QNX we did change the classloader hierarchy to include ext, and we 
bundle-ified the swt-javafx jar. Worked but not sure we can do that in the 
Eclipse context.

Thanks,
Doug.

From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Tom Schindl 
[tom.schi...@bestsolution.at]
Sent: Thursday, August 21, 2014 3:37 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] e(fx)clipse participating in Mars 
release

We are still using OSGi-AdapterHooks but so do others on the release
train as well but we are not modify any classpath nor do we modify the
classloader strategy of Equinox so I can't see how we can affect others
inside the IDE.

As far as I can tell there's no other option than Adapter-Hooks to get
JavaFX embedded in the Eclipse IDE because the swt-javafx bridge is not
on ANY classpath.

For JavaFX8 in OSGi without adapter-hooks you'd have to modify the
Equinox-Classloader hierarchy to include the extension-classpath which
most likely breaks many other things and would still not fix your
swt-javafx embedding.

Other IDEs built on top of Eclipse (e.g. STS) have already adopted our
AdapterHook and so do others like GEF4 and hopefully many others as well.

To sum up, I can't see how having e(fx)clipse on the release train (and
maybe in a download package) can affect others using JavaFX beside
takeing the burden to understand how much such an integration has to
work in every detail.

Tom

On 21.08.14 09:23, Max Rydahl Andersen wrote:
 On 20 Aug 2014, at 10:46, Tom Schindl wrote:

 Hi,

 e(fx)clipse would like to join the Mars release as a +3 component
 because we depend on Xtext who is +2.

 Our current plan is to contribute e(fx)clipse 2.0 because this is the
 first time we are joining (I need to make myself familiar with the
 process) I'm not sure we manage to contribute to M1 in time.

 I'm curious - Did you find a way to use javafx without doing tweaks on
 the classpath/eclipse.ini
 that potentially affect others using javafx ?

 /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
___
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] What policy w.r.t. javafx package imports?

[Doug Schaefer]

That's a really good question. It's easier as an external product since we 
already redist the Oracle VM and kinda cheat a little to get these jar files 
put into the right spot. I'm not sure how that's possible with the Eclipse IP 
rules.

And, at the end if the day, these jar files only exist in an Oracle/OpenJDK VM 
environment. The current execution environments don't take that into account. 
We may need a new one that separates out this variant of JavaSE7 and 8.

Doug.


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Alexander Nyßen 
[alexander.nys...@itemis.de]
Sent: Monday, August 18, 2014 3:59 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] What policy w.r.t. javafx package 
imports?

I temporarily disabled all GEF4 features that (directly or indirectly) depend 
on JavaFX. I do not know what is the intended offset of e(fx)clipse, but unless 
we find out how to provide these dependencies (i.e. jfxrt.jar in case of Java7, 
jfxswt.jar in case of Java8) to B3 directly (i.e. jfxrt.jar in case of Java7, 
jfxswt.jar in case of Java8) we will have to re-enable them after e(fx)clipse 
has joined (and potentially update our contribution).

Cheers
Alexander

Am 18.08.2014 um 21:43 schrieb Alexander Nyßen 
alexander.nys...@itemis.demailto:alexander.nys...@itemis.de:

Would that mean I have to specify dependencies to e(fx)clipse or would b3 
resolve this implicitly? Up to now, my bundles only specify javafx package 
imports (including imports to javafx.embed.swt)...

Cheers
Alexander

Am 18.08.2014 um 21:40 schrieb Tom Schindl 
tom.schi...@bestsolution.atmailto:tom.schi...@bestsolution.at:

a) e(fx)clipse just released 1.0
b) the bundles required only depend on equinox = Luna

So no matter if we (efxclipse) are on the Mars release GEF4 should be fine!

Tom

Von meinem iPhone gesendet

Am 18.08.2014 um 21:22 schrieb David M Williams 
david_willi...@us.ibm.commailto:david_willi...@us.ibm.com:

And, in the mean time, it seems your current contribution won't aggregate 
(and mentions missing things somehow related to fx. Can you disable those 
features for now?

For the record, if the required project did not participate, you can 
include their features in yours, but, only from their latest released version 
(if there is one ... and if there is not a released version, then you could not 
do it).

Thanks,




From:Alexander Nyßen 
alexander.nys...@itemis.demailto:alexander.nys...@itemis.de
To:Cross project issues 
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org,
Date:08/18/2014 12:58 PM
Subject:[cross-project-issues-dev] What policy w.r.t. javafx package
imports?
Sent by:
cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org




Hi all,

as some of the new GEF4 bundles we want to include with Mars specify javafx 
package imports (so far without version constraints), I was wondering what 
general policy we want to follow to ensure such kind of bundles can be properly 
resolved. Should we rely on the e(fx)clipse runtime bundles/fragments 
(org.eclipse.javafx and org.eclipse.fx.osgi), i.e. re-bundle them in our 
features or specify feature-dependencies to the enclosing e(fx)clipse runtime 
feature, or is there another intended way (it seems, e(fx)clipse has not 
announced its participation)?

Cheers
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.dehttp://www.itemis.de/
alexander.nys...@itemis.demailto: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: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

[attachment signature.asc deleted by David M Williams/Raleigh/IBM] 
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.orgmailto: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.orgmailto: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.orgmailto:cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your 

Re: [cross-project-issues-dev] Xtext Contribution to SR1

[Doug Schaefer]

I think that should be fine. I think the requirement is to have the release 
review completed by RC1. The bits can ship whenever.

For CDT, for example, the SR is our release so we ship when it ships.

HTH,
Doug


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Sven Efftinge 
[sven.effti...@itemis.de]
Sent: Tuesday, July 08, 2014 11:16 AM
To: Cross project issues
Subject: [cross-project-issues-dev] Xtext Contribution to SR1

Hi all,

I wanted to inform everyone that the Xtext project plans to contribute a minor 
release (2.7) to SR1.
The plan is to release version 2.7 on September 2nd, which is +2 for RC2 [1]. 
We will contribute to RC1 as well of course.

Would it be possible to contribute a 2.7.1 to RC3 in case we encounter a 
serious problem?

Regards,
Sven

[1] - https://projects.eclipse.org/projects/modeling.tmf.xtext/releases/2.7.0
___
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