[cross-project-issues-dev] Partial Oxygen M1 repository is available

[David M Williams]

Oxygen M1 only contains about one-third of what it normally does, so I am 
not sure how useful it will be, or how much testing can be done, but, what 
we have is available at 
http://download.eclipse.org/releases/oxygen/

As announced on EPP list, there will be no EPP packages for this 
milestone. 

Good time to keep up the momentum, though. Anyone "not quite" in M1, can 
contribute at any time (for "staging"), even if your final contribution 
comes later. 

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] Status and outlook for Oxygen M1

[David M Williams]

Since there still so many disabled contributions for M1, I will extend the 
deadline to Thursday 5 PM, just in case anyone wants to correct anything, 
or contribute more. 

For example, I noticed even if I enable everything, the aggregation still 
fails due to m2e referring to a repo at 
http://download.eclipse.org/technology/m2e/releases/1.8/1.8.0.20160809-1624
And I wonder if that was a "typo" (since it just changed, and the comment 
mentioned "milestones"). 

There are currently 427 features in "staging". Normally there are about 
1200. I have asked Markus if any EPP packages could be created, but I 
recall in years past, we could not create EPP packages at M1, because 
participation was so low. 

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] Announcing my changing job status

[David M Williams]

Some of you may have noticed from reading other lists that I have resigned 
two Project Lead positions and announced I would no longer be working for 
IBM after 8/16.  While many committers at Eclipse change jobs, employers, 
or retire, most do not make a public announcement about it -- after all, 
it does not affect one's status as a committer.  But, I thought I should 
say something to this list since 
a. I won't be able to do near as much work I have been doing while 
employed by IBM, 
b. my departure will impact several projects 
c. but I will not stop doing software engineering and, 
d. most importantly, I will NOT be ending my involvement in the 
Simultaneous Release -- well, at least, not immediately. 

The Eclipse Foundation and I have agreed I will work (part-time) under 
contract to them through December to be sure Neon (.1 and .2) and Oxygen 
M4 are all released with minimal churn. Also, there are some things to 
simplify, document, and put in place in CBI -- all so that my successor(s) 
can take over more smoothly. [BTW, Mike and the Planning Council have 
known this was coming for several months ... but I asked them not to 
mention it publically until I did, and it has taken me that long to write 
a note this short. :) ] 

As for some of my other roles: 
My role in Eclipse Platform Releng is transitioning gracefully to Sravan 
Lakkimsetti. (Thanks, Sravan!)
My role in Orbit is transitioning gracefully to Roland Grunberg (Thanks, 
Roland!)

I do not know what projects I will work on in the future. But, I do know 
that my immediate plans (other than a little more Sim. Release work) are 
to rest, play, and contemplate the state of the universe -- at least for 
several months -- before making any long term decisions.  I'd love to stay 
involved in Eclipse if things happened to work out that way, but, there 
are a lot of open source projects out there in the world (and related 
opportunities), and I have never had time to look at them nearly as much 
as I would like to.  I am grateful to have been able to work full time "in 
Eclipse" since 2004 when WTP started. And while I am not exactly saying 
"goodbye," I will miss working as closely and intensely as I have been 
with many of you and other individuals and teams in Eclipse. 

If anyone needs to contact me (outside the dev lists or bugzilla) -- 
especially after 8/16 -- best for now to use my personal email, which is 
daddav...@gmail.com. 

Thanks for reading, 


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] GEF Oxygen M1 contribution only partially today

[David M Williams]

s that depend on each 
other. Is there any cycle in the dependency graph?

Even if there is no cycle (which could well be on the level of projects), 
there are several downstream dependencies (Ed and I have already pointed 
out two).


We are not building the Oxygen SimRel from scratch. It is based on the 
Neon state. 

No, it isn’t. The Neon contributions are all disabled by default.

What have changed so significantly during Oxygen M1 so these project 
cannot stage their contributions incrementally?

Nothing. Because of the downstream dependencies that exist, there is a lot 
of bootstrapping required for M1. As the Neon contributions are disabled, 
enabling a feature can only be performed after all prerequisites have been 
contributed to M1. This is the root cause...


Kaloyan

Regards,
Alexander


From: cross-project-issues-dev-boun...@eclipse.org <
cross-project-issues-dev-boun...@eclipse.org> on behalf of Alexander Nyßen 
<nys...@itemis.de>
Sent: Tuesday, August 9, 2016 4:38:00 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today
 
I also fear that without enabling the Neon contributions the bootstrapping 
is not to be done. We are virtually postponing it all to Wednesday, when 
we will have to perform a piece-by-piece integration (probably on the 
level of individual features), hoping that all projects actually 
contribute something. GEF for instance depends on e(fx)clipse and Xtext, 
which - if I recollect correctly - have not even stated their intention to 
participate in Oxygen. I am keeping my fingers crossed...

Regards
Alexander

Am 09.08.2016 um 14:36 schrieb Ed Willink <e...@willink.me.uk>:

Hi

Co-ordination would be good, but we have a new policy whose consequences 
do not seem to have been appreciated.

Indeed it is +2, and I see no successful +1 contributions. Just GEF that 
enabled a Neon contribution to reduce its small contribution to the 
overall deadlock.

Regards

Ed Willink

On 09/08/2016 13:27, Kaloyan Raev wrote:
Hi Ed,

Can't all these projects coordinate and make the necessary contributions 
within a short time frame without leaving master broken for a long time?

It's already M1 +2 date and the rest of the projects should be able to do 
their contributions.

Kaloyan

From: cross-project-issues-dev-boun...@eclipse.org 
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Ed Willink 
<e...@willink.me.uk>
Sent: Tuesday, August 9, 2016 3:20:07 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today
 
Hi

Feel free, but we have a policy problem.

The earlier discussion was on Xtext dependencies.

The build is currently failing because OCL depends on UML2 which is 
missing.

Once UML2 is fixed, OCL and/or UML2 will fail because EMF and/or Xtext is 
missing.

We therefore have three choices.

Green all the way: No contribution is enabled till ALL prerequisites are 
enabled. This will be very slow because of the recursive dependencies, 
because relengs are not super-responsive, because it is August, because 
some projects never contribute at M1, and because M1 used to be two rather 
than one weeks long.

Red till green: contribute as normal, so that the validator identifies the 
missing contributions.

The old way. Neon contributions are enabled by default.

I think the old way was better, but given that we are improving, I see 
contribution enabling as appropriate so that the missing contributions are 
highlighted.

AFAIAA all OCL's dependencies have declared intent so OCL can be enabled 
and that is what I have done.

Regards

Ed Willink

On 09/08/2016 13:09, Kaloyan Raev wrote:
Hi folks,

I don't want to break the party, but your recent changes, pushed directly 
to master, broke the validation build. Thus, everyone else who follow the 
clean process of contributing via Gerrit is blocked at the moment.

I am going to revert the last changes one by one until I get a clean 
validation build.

Please contribute your next changes via Gerrit.

Thanks,
Kaloyan

From: cross-project-issues-dev-boun...@eclipse.org 
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Ed Willink 
<e...@willink.me.uk>
Sent: Monday, August 8, 2016 8:39:57 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
partially today
 
Hi
XText has declared intent. XText releases asynchronously, so it is very 
likely that Xtext 2.10 crosses the boundary.
It seems unhelpful that you have inhibited aggregation contributions just 
because the XText releng has not realized how much trouble your 
enabled=false is causing.
I'll enable OCL so that things improve as soon as XText and friends 
appear.
Regards
Ed Willink
On 08/08/2016 18:27, David M Williams wrote:
> Can we have the Neon contributions available as in previous years?

Projects ca

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

[David M Williams]

> Can we have the Neon contributions available as in previous years?

Projects can do that, if they want -- as long as it is still "fits in". 
But it is up to the project. They need to "declare intent" and provide a 
release record, AND THEN re-enable what every contribution they want to 
make. 

Thanks, 





From:   Ed Willink 
To: cross-project-issues-dev@eclipse.org, 
Date:   08/08/2016 12:13 PM
Subject:Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
only partially today
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi
OCL too cannot be enabled until Xtext is enabled.
I feel that this attempt to bootstrap from nothing is going to make for 
some very tight late coordination.
Can we have the Neon contributions available as in previous years?
If enabled="false" is required to enforce announced participation, surely 
it would be better to apply it just after M2 to all projects that have 
made no SimRel commit since Neon?
Regards
Ed Willink


On 08/08/2016 16:34, Alexander Nyßen wrote:
Hi all, 

I have just re-enabled the GEF repository for Oxygen and made available 
the Neon release version of GEF-legacy (Draw2d/GEF (MVC) 3.x, Zest 1.x) to 
enable downstream projects that depend on it. The GEF (formerly known as 
GEF4) contribution to M1 is already prepared as well, but I had to disable 
it for now because it depends on downstream projects (namely e(fx)clipse 
and Xtext) that have not updated their contributions yet. GEF will thus 
not be available today but on Wednesday.

Regards,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
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

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, 
Jennifer Fiorentino





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





This email has been checked for viruses by Avast antivirus software. 
www.avast.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] Oxygen(4.7) M1 is available

[David M Williams]

Yes, once Oxygen M1 is done. (due this Friday, 8/12). 

In the mean time, if you wanted to do "test installs" you can use 
http://download.eclipse.org/staging/oxygen/

As always, I don't recommend using the Sim. Release repo for builds. 
Better to use the original "source" repositories that you depend on. 

For exact plans for Oxygen, see 
https://wiki.eclipse.org/Oxygen/Simultaneous_Release_Plan#Schedule

Thanks, 




From:   "Sievers, Jan" 
To: Cross project issues , 
Date:   08/08/2016 03:17 AM
Subject:Re: [cross-project-issues-dev] Oxygen(4.7) M1 is available
Sent by:cross-project-issues-dev-boun...@eclipse.org



will latest oxygen milestones also be added to a composite repo

http://download.eclipse.org/releases/oxygen/ ?

we used to have this for previous releases, see e.g. Mars

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


Regards
Jan

On 05/08/16 17:30, "cross-project-issues-dev-boun...@eclipse.org on behalf 
of Sravan K Lakkimsetti"  wrote:

We are pleased to announce that Oxygen M1 is available for download 
and updates.
 
Eclipse downloads:

http://download.eclipse.org/eclipse/downloads/drops4/S-4.7M1-201608032000/
 
Update existing (non-production) installs:
http://download.eclipse.org/eclipse/updates/4.7milestones/
 
Specific repository good for building against:

http://download.eclipse.org/eclipse/updates/4.7milestones/S-4.7M1-201608032000/

 
Equinox specific downloads:
http://download.eclipse.org/equinox/drops/S-OxygenM1-201608032000/
 
Please note Eclipse has dropped support for the following Unix based 
platforms: AIX, Solaris, HP-UX and Linux s390. The builds for these 
platforms are not available on the eclipse.org downloads page.
For more information, please read the announcement <
https://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg10207.html> made by 
the Eclipse PMC
 
Also we don't have Linux PPC64LE platform for this release due to 
unforeseen circumstances. This will be available from M2.
 
Thank you to everyone who made this checkpoint possible.
 
 
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
 
 
 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Ready for Neon.1 checkpoint? Oxygen M1?

[David M Williams]

As previously announced, we now have a "checkpoint build" for Neon.1 
especially intended for projects that are new to Neon.1. 

If I have followed the notes to this list correctly (and cross-project 
bugs)  the only two projects that are new to Neon.1 are Window Builder and 
BPMN2 Modeler. Since the deadline is tomorrow (8/27), I thought I would 
try to enable them in Neon_maintenance to see what would happen. The 
aggregation worked, but I have no idea if the content there is what the 
projects intend. These projects have to still check that. 

If there are other projects joining Neon.1 that are not in the checkpoint 
build, please follow the Exception Process.  

If there are questions about dates or process please read the Neon plan 
and after reading that if there are any remaining questions please ask 
here on this list. The Neon.1 RCs will be starting sooner than you may 
think (8/19). 

And speaking of sooner than you think, Oxygen M1 begins on 8/5! Please see 
the Oxygen Plan for more details.

I have updated the Planning Council calendar through December of this year 
(through Oxygen M4 and Neon.2). 

Please bookmark these links, and plan accordingly. 

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] New to Neon.1? Please "announce" and be sure Release Record is accurate.

[David M Williams]

I am not sure we have been very explicit about it so I will be now. 

For anyone that is joining the Neon train in the update release of Neon.1 
please announce here on this list and be sure your release record is "up 
to date" to reflect the September date. 

I think in some cases, people may have long ago said they would be skip 
Neon and be in Neon.1, but a new announcement here would be appreciated 
... just as a reminder and for easier "book keeping". 

And, don't forget, if new to Neon.1 you should be in "checkpoint" build, 
(by July 27 at the latest) and then RCs start a month after that. 

Thanks as always, 



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

[David M Williams]

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] Dates for Neon Update releases and Oxygen Milestones; changes; and declaring for Oxygen.

[David M Williams]

The streams have been split and the aggregation builds are open for 
business. See 
Bug 497877 - Split streams in org.eclipse.simrel.build and setup 
aggregation builds 
for details. 

As always, the builds are at 
https://hudson.eclipse.org/simrel/

Use refs/for/Neon_maintenance for Gerrit changes intended for Neon.1 and 
refs/for/master for Gerrit changes intended for Oxygen. 

And, remember, anyone that is new to Neon.1 should join the build by the 
7/27 checkpoint at the latest. If questions or issues, please ask here, or 
open a cross-project bug if you need help. 

And, for Oxygen, remember to prepare your release records and "declare 
intent" here soon -- and then contribute to the aggregation build soon 
after! 

Thanks, 






From:   David M Williams/Raleigh/IBM@IBMUS
To: cross-project-issues-dev@eclipse.org, 
Date:   07/12/2016 06:04 PM
Subject:[cross-project-issues-dev] Dates for Neon Update releases 
and Oxygen Milestones; changes; and declaring for Oxygen.
Sent by:cross-project-issues-dev-boun...@eclipse.org



The planning council has approved some exact dates for the Neon Update 
releases 
https://wiki.eclipse.org/Neon/Simultaneous_Release_Plan#Schedules

and the Oxygen Milestones: 
https://wiki.eclipse.org/Oxygen/Simultaneous_Release_Plan#Schedule

They do come out at about the same time so there will be work to do that 
overlaps one with the other. Please plan accordingly. 

We will update the Google calendar soon. 

= = = = = = = = = = = = 

Some small differences from previous years: 

- The Update releases will formally, simultaneously release mid-week 
instead of on Friday's, which makes their "quiet week" more like a week 
and a half. 
- There is no longer a "warm-up" RC two weeks in advance of RC2: we expect 
all RC's to be strong release candidates. 
- There is no longer a two-week window for the initial three milestones. 
The Planning Council felt that (and the warm-up RC) were left-over 
processes when we were all much less experienced at this, and now most 
projects are very skilled at it, so those buffers are no longer needed. 

= = = = = = = = = = = = 

A larger change for the Update Releases. 

There will be a "milestone" of sorts for each Update Release. We call it a 
"checkpoint" in this context since there is only one of them. This 
checkpoint build is primarily for new projects just joining the train for 
the first time, or for projects which have very significant changes. Other 
projects may contribute to them if they would like but in most cases, we 
recommend not to, so that we have a steady target for the new projects to 
hit. These checkpoints are one month before the first RC, which means the 
fist one is not far off -- 7/22 to 7/27. (No EPP packages for checkpoint 
builds.) Our goal is to allow those new to the process to learn and get 
through the mechanics of contributing to the aggregation build at a time 
that is less stressful than the rapid fire RC period as well as improve 
communication about who or what is new in the Update releases. 

= = = = = = = = = = = = = 

I will split streams on Wednesday. All those in Neon will assume to be 
still in Neon.1 unless they formally withdraw. 
For Oxygen, I will mark all contributions as "disabled" until projects 
declare their intent, and create a Release Record. 
At that point, you may re-enable your contribution, but you may need to 
wait to commit it until all your prereq projects have joined (that is, 
just leave in in Gerrit until it passes validation there). 

= = = = = = = = = = = = =

Thanks to you all! 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Dates for Neon Update releases and Oxygen Milestones; changes; and declaring for Oxygen.

[David M Williams]

The planning council has approved some exact dates for the Neon Update 
releases 
https://wiki.eclipse.org/Neon/Simultaneous_Release_Plan#Schedules

and the Oxygen Milestones: 
https://wiki.eclipse.org/Oxygen/Simultaneous_Release_Plan#Schedule

They do come out at about the same time so there will be work to do that 
overlaps one with the other. Please plan accordingly. 

We will update the Google calendar soon. 

= = = = = = = = = = = = 

Some small differences from previous years: 

- The Update releases will formally, simultaneously release mid-week 
instead of on Friday's, which makes their "quiet week" more like a week 
and a half. 
- There is no longer a "warm-up" RC two weeks in advance of RC2: we expect 
all RC's to be strong release candidates. 
- There is no longer a two-week window for the initial three milestones. 
The Planning Council felt that (and the warm-up RC) were left-over 
processes when we were all much less experienced at this, and now most 
projects are very skilled at it, so those buffers are no longer needed. 

= = = = = = = = = = = = 

A larger change for the Update Releases. 

There will be a "milestone" of sorts for each Update Release. We call it a 
"checkpoint" in this context since there is only one of them. This 
checkpoint build is primarily for new projects just joining the train for 
the first time, or for projects which have very significant changes. Other 
projects may contribute to them if they would like but in most cases, we 
recommend not to, so that we have a steady target for the new projects to 
hit. These checkpoints are one month before the first RC, which means the 
fist one is not far off -- 7/22 to 7/27. (No EPP packages for checkpoint 
builds.) Our goal is to allow those new to the process to learn and get 
through the mechanics of contributing to the aggregation build at a time 
that is less stressful than the rapid fire RC period as well as improve 
communication about who or what is new in the Update releases. 

= = = = = = = = = = = = = 

I will split streams on Wednesday. All those in Neon will assume to be 
still in Neon.1 unless they formally withdraw. 
For Oxygen, I will mark all contributions as "disabled" until projects 
declare their intent, and create a Release Record. 
At that point, you may re-enable your contribution, but you may need to 
wait to commit it until all your prereq projects have joined (that is, 
just leave in in Gerrit until it passes validation there). 

= = = = = = = = = = = = =

Thanks to you all! 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Anyone know of a reason NOT to upgrade the "shared instance" Hudson?

[David M Williams]

This is the one at 
https://hudson.eclipse.org/shared/


Please comment in bug if you know of a reason NOT to upgrade, otherwise we 
will plan on doing an upgrade on Tuesday morning, 7/12. 

Bug 497587 - Upgrade shared Hudson to 3.3.2 (or 3.3.3) 

(And, I think shared takes a long long time, because it has a lot to 
"backup" first -- maybe a few hours?) 




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Remember to update b3aggrcon files with your "final URL" for Neon

[David M Williams]

I know a few of you have, already, but if not, please remember to update 
your b3aggrcon files with your final "released" p2 repository URL. 

I have "turned on" the Sim Release aggregation builds (except not yet 
"promote to Staging") just so that as people put in their "final URLs for 
Neon" the system will automatically check that everything is "still OK". 
(So, if you get a "failure notice" please attend to it). 

Why bother changing your URL? Well, besides being a good citizen :) in a 
week or two I will "split streams" so we have one for Neon Update Releases 
and one for Oxygen so you might save your self some trouble then if you 
plan to leave your "released build URL" the same in both streams for a 
month or more. But, most important, we want aggregation build to "always 
work" even as you clean up (remove) your non-released URLs. 

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] The Neon Simultaneous Release is available!

[David M Williams]

The eleventh yearly Simultaneous Release -- since beginning with Callisto 
in 2006! How we've grown and changed since then! 

The main repository is at 

  http://download.eclipse.org/releases/neon/

The EPP (all-in-one) packages are available at 

  https://www.eclipse.org/downloads/eclipse-packages/

The main download page has been redesigned, but is still at 
 
  https://www.eclipse.org/downloads/

And the beautiful main landing page is at 

  https://www.eclipse.org/neon/

Pass the word! 

As always, I have the greatest respect for all who worked through the 
issues to get this release out and you have my sincerest thanks. Our users 
"thanks" will surely follow. :) 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Respin of SimRel Repository required

[David M Williams]

My apologies for not communicating more quickly the information back to 
this list. Entirely my oversight. 

The final EPP packages themselves are available from: 

  
https://hudson.eclipse.org/packaging/job/neon.epp-tycho-build/388/artifact/org.eclipse.epp.packages/archive/


If anyone wants to try an "update scenario you should use the following 
two repositories. (And have only them enabled.) 

But, remember, the main "test result" ... at least from previous EPP 
installations ... is that you should "not be allowed to update". If you 
were, the new installation would be broken since there was such a large 
change in structure from previous (Mars) version of EPP packages. 

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

Assuming no "catches the machine on fire" type bugs these will become our 
Neon release on 6/22. 

Thanks, 





From:   Matthias Sohn <matthias.s...@gmail.com>
To: Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:   06/15/2016 06:05 PM
Subject:Re: [cross-project-issues-dev] Respin of SimRel Repository 
required
Sent by:cross-project-issues-dev-boun...@eclipse.org



any update on the current status of the repository and availability of 
packages for testing ?

On Mon, Jun 13, 2016 at 6:07 PM, David M Williams <
david_willi...@us.ibm.com> wrote:
Extended team, 

I am beginning a re-spin of the Sim. Release repository. 

Two major changes: SOA-BPN2 modeler removed and Window Builder removed. 

The former removed because they didn't finish the normal release 
requirements. The later was removed because it has not been tested with 
the Neon candidate release. (It did recently, after RC4, get a build which 
"removed one line of code" which prevented it from running on Neon ... 
but, our goal is not for projects to "join at the last minute" but to be 
part of the train for many milestones so it can be adequately tested). 

It is my understanding both projects plan to "rejoin the train" in the 
September release. 

A minor change: Linux Tools found a major memory leak which would normally 
not be "respin worthy", but I told them if we had to respin for other 
reasons they could include a fix for that. 

The EPP packages will need to be rebuilt of course -- first because they 
always are if the repository changes, but more so this time because Window 
Builder was included in two EPP packages and of course will have to be 
removed from those packages. 

I will update this list once both steps are complete. 

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

[cross-project-issues-dev] Respin of SimRel Repository required

[David M Williams]

Extended team, 

I am beginning a re-spin of the Sim. Release repository. 

Two major changes: SOA-BPN2 modeler removed and Window Builder removed. 

The former removed because they didn't finish the normal release 
requirements. The later was removed because it has not been tested with 
the Neon candidate release. (It did recently, after RC4, get a build which 
"removed one line of code" which prevented it from running on Neon ... 
but, our goal is not for projects to "join at the last minute" but to be 
part of the train for many milestones so it can be adequately tested). 

It is my understanding both projects plan to "rejoin the train" in the 
September release. 

A minor change: Linux Tools found a major memory leak which would normally 
not be "respin worthy", but I told them if we had to respin for other 
reasons they could include a fix for that. 

The EPP packages will need to be rebuilt of course -- first because they 
always are if the repository changes, but more so this time because Window 
Builder was included in two EPP packages and of course will have to be 
removed from those packages. 

I will update this list once both steps are complete. 

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

Re: [cross-project-issues-dev] Simrel validation fails for Jetty

[David M Williams]

I forgot to attach the "patch" as I said I would. When these projects are 
ready to commit new versions, just remove the enabled="false" attribute. 

diff --git a/rap-tools.b3aggrcon b/rap-tools.b3aggrcon
index da65673..ae5b1cd 100644
--- a/rap-tools.b3aggrcon
+++ b/rap-tools.b3aggrcon
@@ -4 +4 @@
-
+
diff --git a/webtools.b3aggrcon b/webtools.b3aggrcon
index 0048050..9ca1c0d 100644
--- a/webtools.b3aggrcon
+++ b/webtools.b3aggrcon
@@ -54 +54 @@
-    
+    




From:   David M Williams/Raleigh/IBM@IBMUS
To: Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:   06/07/2016 09:04 PM
Subject:Re: [cross-project-issues-dev] Simrel validation fails for 
Jetty
Sent by:cross-project-issues-dev-boun...@eclipse.org




> In particular we haven't changed anything in CDO between RC3 and 
> RC4. Does someone know what this can mean and what I 
> can do to get my contribution through?

I do! Its all related to the jetty change Carl mentioned. While the 
Platform has not been "contributing" Jetty 9.3.5 for a week or two, I 
suspect someone else was, thus no issues, and now that "other project" has 
also moved up to 9.3.9. 

There are actually two issues: 

Rap Tools, and 
Web Tools Server adapters.

Below is a patch showing what I could disable, and allow the validation to 
still succeed. I'm sure that functionality will be broken, and EPP package 
may not even build, until Webtools and RapTools actually submit a fix, but 
in the mean time, I will submit these "disabled" versions of RAP Tools and 
Webtools, just so others can validate as best you can. 

I hope that helps, 
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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 validation fails for Jetty

[David M Williams]

> In particular we haven't changed anything in CDO between RC3 and 
> RC4. Does someone know what this can mean and what I 
> can do to get my contribution through?

I do! Its all related to the jetty change Carl mentioned. While the 
Platform has not been "contributing" Jetty 9.3.5 for a week or two, I 
suspect someone else was, thus no issues, and now that "other project" has 
also moved up to 9.3.9. 

There are actually two issues: 

Rap Tools, and 
Web Tools Server adapters.

Below is a patch showing what I could disable, and allow the validation to 
still succeed. I'm sure that functionality will be broken, and EPP package 
may not even build, until Webtools and RapTools actually submit a fix, but 
in the mean time, I will submit these "disabled" versions of RAP Tools and 
Webtools, just so others can validate as best you can. 

I hope that helps, 


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] removal of UUID in Eclipse Platform -- new build at I20160606-1100

[David M Williams]

This is the build that has the fix for bug 495484 and (I hope) our final 
build for Neon. 

http://download.eclipse.org/eclipse/downloads/drops4/I20160606-1100/

After the unit tests complete I will rename it, promote to download 
server, and update the b3aggrcon file. 
I plan to call it "RC4a"l

Since the tests take so long, it will be late tonight or early tomorrow 
that the new name appears on downloads server, and I just wanted to give 
this "early notice" in case anyone was building against or testing with 
the "final version", then you could safely use the I20160606-1100 build. 

Thanks, 




From:   Markus Knauer 
To: Cross project issues , 
Date:   06/05/2016 08:09 AM
Subject:Re: [cross-project-issues-dev] New UUID in Eclipse 
Platform
Sent by:cross-project-issues-dev-boun...@eclipse.org




On 5 June 2016 at 11:43, Ed Willink  wrote:
What is the process for requesting a respin to have the UUID facility 
removed pending a more acceptable realization?

I've opend bug 495484

  Bug 495484 - Remove unique user tracking id in Neon
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=495484

to officially ask for removal and re-spin of RC4.


On 5 June 2016 at 13:43, Stephan Herrmann  
wrote:
Technical question: is disabling UUID s.t. which EPP can do?

As far as I can see: No.


Thanks,
Markus

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] The Platform's official RC4 not declared until Saturday

[David M Williams]

We in the Platform re-built several times for RC4, the final one being: 

http://download.eclipse.org/eclipse/downloads/drops4/I20160603-1000/

But since it was not done until 2:00 today, the Unit tests are still 
running.  As a matter of good practice, I won't officially rename and 
declare the Eclipse Platform's RC4 until the unit tests are finished, 
which won't be until very late tonight. 
So, those waiting to do a final build with our final build could use 
I20160603-1000 with high confidence, but you won't see the "RC4" label 
until Saturday. 

= = = = =

I will also mention that anyone who uses "Jetty" from the Platform should 
definitely rebuild and/or change your pre-req to the 9.3.9 version of 
Jetty.  We moved up from 9.3.5 to 9.3.9 after RC3, so ideally we will end 
up with just one version of Jetty in our repository. . Normally, we 
wouldn't change versions so late, but this was a special case. (See 
Bug 495069)

= = = = =

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] Neon RC3 is now available

[David M Williams]

Neon RC3 is now available for update at the built in URL of 
.../releases/neon, which now has RC3, RC2 and RC1 in its composite. 

The EPP packages are available from the "developers tab" at 
www.eclipse.org/downloads (unless it is waiting for the package maintainer 
to confirm it). 

Thanks all for your contributions. 

One more to go! 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] RC3 staging repo is complete

[David M Williams]

It was as of about 8 PM last night. 
Sorry for the delay of sending notice. 


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Everyone ready for the Neon Release? Or at least the Final Daze?

[David M Williams]

I know we have not even delivered RC3 yet! :) 

But, I have tweaked our Neon Final Daze document and opened our Neon info 
center bug.

Those that are new to the process will enjoy reading the entire Final Daze 
document. Those that are familiar with the process, may want to review it, 
but here is a summary: 

 - Clean up old releases and intermediate builds such as milestones. 
 - Be sure you understand and use the p2.mirrorsURL property in your 
repositories, and the "download.php" mirror link in your download pages 
when linking to your download artifacts.
 - Please don't make final announcements or final deliverables available 
until our Simultaneous Release date (6/22). 
 - But do put your final artifacts in final locations so they can mirror, 
but leave "invisible". The Final Daze document has some "how to" 
references, if you don't know what that means. 
 - Update the info center bug when your doc bundles are final, so your 
documentation can be included in online help.

Those I mention by name in the Final Daze document should take a peak and 
make sure I have the right names :) and the right tasks.  
 
  - Markus
  - Denis
  - Christopher
  - Roxanne

As always, if you have questions, feel free to ask here on this list, 
since if you have the question, others probably do too. 

Thanks as always, 





___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Neon RC2 is complete

[David M Williams]

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] Is it Wednesday yet? :) The staging repo for RC2 is complete

[David M Williams]

It was complete a long time ago, I was just preoccupied with a bad bug and 
forgot to announce. 

Thanks, 


P.S. For once I agree with Mickael. A failed build is not "bad" in cases 
like we saw with EGit's qualifier being wrong -- if for no other reason 
than we don't know if the qualifier was wrong. Perhaps something is wrong 
with their deployment or build, and a "loose" requirement would have made 
them miss that fact. Whereas now they have to investigate and explain 
themselves. :) Well, I hope they do! The only mistake they made was 
hitting "commit" and not waiting around to see what happened (perhaps 
because BIRT or others broke the build? (just a possible example -- I am 
guessing) and they could not wait around for BIRT to fix the build? Could 
be many reasons why, and I don't blame any one team as much as I sometimes 
sound, because we should all be acting like "one team - one product" when 
it comes to the Sim. Release! 

To "do a build" is easy. To do a build correctly is hard. 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Fwd: Change 73676 insimrel/org.eclipse.simrel.build[master]: Update PTP to RC2

[David M Williams]

> ... 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] Neon RC1 is now available

[David M Williams]

I have "flipped the switch" to make the repositories visible to p2 clients 
from the .../releases/neon URL. 

The EPP packages will be available from their usual "developers tab" at 
www.eclipse.org/downloads. 

Thanks everyone for making RC1 available. 

The RCs will be coming out fast and furious now ... one week apart ... 
ideally each with very few changes from the previous. 

Much 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] Neon RC1 staging is complete

[David M Williams]

Test early, test often: http://download.eclipse.org/staging/neon/

Assuming no blockers found while producing EPP packages this staging 
repository will be added to the 
http://download.eclipse.org/releases/neon/ 
repository on Friday, approximately 10 AM. 

Thanks everyone, 

And especially thanks to everyone for keeping us informed of changes. 




From:   Marc-André Laperle 
To: Cross project issues , 
Date:   05/18/2016 07:58 PM
Subject:Re: [cross-project-issues-dev] Trace Compass RC1 late
Sent by:cross-project-issues-dev-boun...@eclipse.org



I just updated the Trace Compass RC1 contribution. Apologies for being a 
bit late!

Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Marc-André 
Laperle [marc-andre.lape...@ericsson.com]
Sent: Wednesday, 18 May 2016 4:48 PM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Trace Compass RC1 late

Hi,

We are trying to get our RC1 build ready but due to some build servers 
instability this is taking longer than expected. I expect it should be 
ready around 8PM (EST) or some time before that.

Thank you,
Marc-Andre___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] EMFStore 1.8.0 instead of 1.7.0

[David M Williams]

No objections from me since you have already been contributing milestones, 
and since you have already checked with known adopters. 

Don't forget to update your release record (or, modify one, if 1.7.0 was 
released and add a new one for 1.8.0)  so that the listing is correct at 
https://projects.eclipse.org/releases/neon

Thanks for keeping us informed. 




From:   Johannes Faltermeier 
To: cross-project-issues-dev@eclipse.org, 
Date:   05/17/2016 11:14 AM
Subject:[cross-project-issues-dev] EMFStore 1.8.0 instead of 1.7.0
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi, 

EMFStore initially announced to contribute the (Mars.2) release 1.7.0 to 
Neon.0 as well. However we would like to include version 1.8.0 [1].
We already contributed 1.8.0 Milestones to Neon and the ECP Project, which 
is the only project with a dependency to EMFStore, is fine with this. Are 
there any objections? 

Regards
Johannes


[1] http://projects.eclipse.org/projects/modeling.emfstore/releases/1.8.0

-- 
Johannes Faltermeier

Software Engineer
EclipseSource Munich

Email: jfalterme...@eclipsesource.com
Web: http://eclipsesource.com/munich
Mobil: +49 178 135 34 62
Phone: +49 89 21 555 30 - 14
Fax: +49 89 21 555 30 - 19

EclipseSource Muenchen GmbH
Agnes-Pockels-Bogen 1
80992 Muenchen

General Managers: Dr. Jonas Helming, Dr. Maximilian Koegel
Registered Office: Agnes-Pockels-Bogen 1, 80992 Muenchen, Commercial
Register Muenchen, HRB 191789
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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 Titan withdraw from Neon

[David M Williams]

> As we’ve been focusing on technical issues, maybe we did not pay 
> sufficient attention to administrative ones. 

Elemér, 

You did not miss any administrative issues. If anyone did that, it was me! 


However, you did miss the train! Not just the end of it, but pretty much 
the whole thing! 

But you (and Yves) have opened my eyes. Something is obviously wrong with 
the way we communicate and manage what mean to be "on the release train".

Thank you, 


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Effective Immediately: no more SimRel maintenance repositories!

[David M Williams]

Still "maintenance" (update releases) just no URL with "maintenance" in 
the path. 

I have made the changes discussed in Bug 483475 so as of now, Neon staging 
repository is at 

http://download.eclipse.org/staging/neon/

And it will remain that as long as we work on Neon! 

When Oxygen development starts, it's staging repo will be 

http://download.eclipse.org/staging/oxygen/

I will delete the old staging repo at .../releases/staging  when I finish 
this note. 

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

Re: [cross-project-issues-dev] Eclipse Titan withdraw from Neon

[David M Williams]

Elemér, 

Thanks for letting us all know. 

Just to be explicit, I assume you were never, and are never, planning to 
be the Simultaneous Release repository? 

I ask since tonight I went to look for a "titan.b3aggrcon" file and did 
not find it. So, I just wanted to be sure I understood your plans or if I 
was missing something. 

Thanks 




From:   Elemér Lelik 
To: "cross-project-issues-dev@eclipse.org" 
, 
Date:   05/11/2016 03:21 AM
Subject:[cross-project-issues-dev] Eclipse Titan withdrarw from 
Neon
Sent by:cross-project-issues-dev-boun...@eclipse.org



Dear all,
 
As we have found some flaws in the 5.4.0 version of Eclipse Titan that has 
been nominated for Neon,  we have chosen with regrets  to withdraw our 
participation.
The issues have been fixed in our upcoming release 5.5.0  but that will be 
too late for Neon.
 
I hope this decision will not upset anyone; there is no known dependency 
we had to  consider.
 
Thank you and best regards
Elemer
 
 ___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Notice that Eclipse Platform plans to no longer provide MD5 and SHA1 checksums for Neon (but still SHA512)

[David M Williams]

The topic of this note is about the downloads and checksums obtained 
directly from the the Eclipse Project. It does not involve the checksums 
from the "select a mirror" page -- that is controlled by the Eclipse 
Foundation -- nor any of the packages downloaded from 
http://www.eclipse.org/downloads -- also controlled by the Eclipse 
Foundation.  My intuition is that few "casual users" use our checksums but 
some adopters or committers might use them in automated scripts or builds. 


If any of you do get checksums directly from 
.../eclipse/downloads/drops4//checksum/... then this note is for 
you. 

We announced in Luna we would "stop producing MD5 and SHA1 checksums" 
after Luna's release (Bug 423714) ... and I am just now getting around to 
it. Since it has been a long time since that announcement, and since we 
are late in this cycle, I am cross-posting to 3 lists to be sure those 
that might be impacted will be notified. 

We will continue to provide SHA512 checksums and I recently decided to 
also provide SHA256 checksums since SHA256 seems to be popular "in the 
industry". 

This RC1 effort is documented in Bug 454784. If the removal of the MD5 and 
SHA1 checksums would unduly burden anyone, please say so in that 
Bug 454784  and we would be happy to accommodate. 

I will soon be updating our wiki on How to verify a download to contain 
accurate information for Neon, but wanted to get this notice out now so if 
you are negatively impacted you would have time to say so. 

Thank you, 






___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Neon M7 is available

[David M Williams]

The M7 repository has been added to the composite at .../releases/neon. 
It now contains M5, M6, and M7. 
Be sure to report if there are any issues due to that "combination" of 
features. 

Many EPP packages are available from the "Developer Builds" tab os 
Eclipse's downloads, namely 
https://www.eclipse.org/downloads/index-developer.php

But, there are quite a few that are still waiting for +1's from the 
package maintainers. We expect them to come rolling in later today or 
Monday. 

Remember, If you (or your users) have an M6 version of an EPP package 
installed, it should "update" to M7, but if you have anything earlier than 
M6, you will need to get a fresh install due to structural changes in the 
packages that were made in M6. 

Thanks to everyone who help get this significant milestone done. Including 
contributors, testers, committers, and the Eclipse Foundation's IT and IP 
teams. 

>From here on, for the "RC phase", please "ramp down" according to your 
project's conventions and procedures so that changes are minimized and 
stability is increased. 

Thanks again, 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Declaring Neon M7 staging repository complete

[David M Williams]

It is worth considering. (Though, doubt I'd have time to work on it any 
time soon).

Accordingly, to track the suggestion I have opened 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=493044 

The long term goal is that each project can run their own reports. 
This is actually possible to do now. 
I have not advertised this much because 1) still quite a few limitations 
with doing so, but mostly 2) must be "run as an Eclipse application" 
(instead of, for example, a maven plugin). 

For those interested in being on the leading-edge and running these 
reports in your own builds, the way I do it in our Platform build is coded 
in a bash script in 
http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/production/createReports.sh
This could serve as a "getting started" example for other projects. Your 
details would vary. 

In general, questions about these reports and running them for individual 
projects can be addressed to the cbi-dev list, since these reports are now 
part of the CBI (Common Build Infrastructure) project. 

Thanks, 





From:   Konstantin Komissarchik <konstantin.komissarc...@oracle.com>
To: David M Williams/Raleigh/IBM@IBMUS, 
"cross-project-issues-dev@eclipse.org" 
<cross-project-issues-dev@eclipse.org>, 
Date:   05/04/2016 11:48 PM
Subject:Re: [cross-project-issues-dev] Declaring Neon M7 staging 
repositorycomplete
Sent by:cross-project-issues-dev-boun...@eclipse.org



Would it be possible to convert reports to e-mail alerts sent to project’s 
mailing list? I suspect we’d get better compliance that way.
 
Thanks,
 
- Konstantin
 
 
 
From: David M Williams
Sent: Wednesday, May 4, 2016 5:42 PM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Declaring Neon M7 staging 
repositorycomplete
 
The iron is cooling and the last Git commit is the last one in "recent 
changes" so I am assuming all is done for M7. 

While EPP packages are being created and tested, be sure to sanity check 
"staging", which is (still) at 

http://download.eclipse.org/releases/staging/

In parallel, this is a good time for project leads to look through the 
most important "repo reports". (There are too many violations for me to 
open bugs on them all). 

http://download.eclipse.org/releases/staging/buildInfo/reporeports/?d

Lots of unsigned jars: (the primary "third segments" are andmore, eef, and 
 m2m. 

http://download.eclipse.org/releases/staging/buildInfo/reporeports/reports/unsigned8.txt


A surprising number of features and bundles missing legal files: 
(primarily in what are new this release: cft and wst.jstd and wst.json) 

http://download.eclipse.org/releases/staging/buildInfo/reporeports/reports/layoutCheck.txt


Other reports are interesting and important for professional looking 
software, but not as "blocking" as the two reports above will become. 

Unless blocking problems are found soon, this staging repo will be 
promoted to .../releases/neon on Friday morning, approximately 10 AM 
(Eastern). 

As usual, I have temporarily paused the Hudson jobs to avoid confusion 
(except for the Gerrit triggered one) and will re-enable them the first of 
next week.

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] Declaring Neon M7 staging repository complete

[David M Williams]

The iron is cooling and the last Git commit is the last one in "recent 
changes" so I am assuming all is done for M7. 

While EPP packages are being created and tested, be sure to sanity check 
"staging", which is (still) at 

http://download.eclipse.org/releases/staging/

In parallel, this is a good time for project leads to look through the 
most important "repo reports". (There are too many violations for me to 
open bugs on them all). 

http://download.eclipse.org/releases/staging/buildInfo/reporeports/?d

Lots of unsigned jars: (the primary "third segments" are andmore, eef, and 
 m2m. 

http://download.eclipse.org/releases/staging/buildInfo/reporeports/reports/unsigned8.txt

A surprising number of features and bundles missing legal files: 
(primarily in what are new this release: cft and wst.jstd and wst.json) 

http://download.eclipse.org/releases/staging/buildInfo/reporeports/reports/layoutCheck.txt

Other reports are interesting and important for professional looking 
software, but not as "blocking" as the two reports above will become. 

Unless blocking problems are found soon, this staging repo will be 
promoted to .../releases/neon on Friday morning, approximately 10 AM 
(Eastern). 

As usual, I have temporarily paused the Hudson jobs to avoid confusion 
(except for the Gerrit triggered one) and will re-enable them the first of 
next week.

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] Is BIRT still viable for Neon. And M7?

[David M Williams]

Do any readers of this list know the status of BIRT? 

Their contribution is still at M5 level. I know Ben tried to produce a new 
M6 at the last minute but could not for some reason. 

I have sent email to bgam...@actuate.com, ch...@actuate.com (just 
yesterday) but have heard no response. Those are the contacts in the 
b3aggrcon file. 

Anyone know of status? Or know of a better contact person or email? 

Or best of all, does anyone from BIRT still read this list? :) 

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

Re: [cross-project-issues-dev] b3 model editor for Mars

[David M Williams]

http://download.eclipse.org/modeling/emft/b3/updates-4.4/

I have had success using it with Mars IDE. 




From:   Matthias Sohn 
To: Cross project issues , 
Date:   04/07/2016 05:41 PM
Subject:[cross-project-issues-dev] b3 model editor for Mars
Sent by:cross-project-issues-dev-boun...@eclipse.org



Where can I find the b3 model editor for Mars which is used to edit the 
aggregator build model ?
I by deleted my Luna Eclipse installation I used earlier for this task and 
now I am wondering
if I can edit the aggregator model using Mars ?

-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

Re: [cross-project-issues-dev] On the issue of building with the latest Orbit repository

[David M Williams]

undles (and the features deployed to simrel), but only use them to 
produce self-contained local drop files (zip).
3) Do not publish all-in-one features on your local update sites either, 
but rather have your local update-sites refer to the simrel update-site 
via an associate-site entry (so Orbit dependencies get pulled in from 
there).

With 1) we would have a single authority that controls which Orbit bundles 
are actually provided in a release, namely the simrel aggregator. 2) would 
cover your use case, Ed. 3) would ensure that newer Orbit bundles (added 
in a maintenance release) would also get picked up when installing from a 
local update-site.

Cheers
Alexander

Am 05.02.2016 um 20:22 schrieb Ed Willink <e...@willink.me.uk>:

Hi Konstantin

I have no idea how a download ZIP can easily mirror something.

But I presume what you really mean is that we should produce two 
ZIPs/categories.

- A contribution ZIP/category that replicates the features contributed to 
SimRel.
- An All-in-One ZIP/category that additionally bundles Orbit facilities 
avoiding the need for users to learn how to include Orbit in the available 
sites.

Regards

Ed Willink

On 05/02/2016 17:33, Konstantin Komissarchik wrote:
I would advise strongly against using the feature includes directive for 
Orbit bundles. While doing so provides a cheap way to mirror the Orbit 
bundle into the produced project repository, it also locks you down to 
using that one version of the bundle and we end up with multiple versions 
of various bundles in the install, often for no good reason. It’s easy 
enough to mirror the required Orbit bundles using a separate step at the 
end of the project build and be free to require the bundle via whatever 
version range is most appropriate.
 
If everyone did this and simrel aggregation included the latest Orbit 
repository, the result of aggregation would contain fewer duplicate Orbit 
bundles without requiring projects to issue a new release just to move to 
a newer version of an Orbit bundle.
 
Thanks,
 
- Konstantin
 
 
From: Ed Willink
Sent: Thursday, February 4, 2016 11:11 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] On the issue of building with 
thelatest Orbit repository
 
Hi David

Interesting if you're right. I thought projects needed to bundle what 
wasn't bundled upstream. Thus OCL bundles LPG since no one else does. OCL 
includes ASM, Guava that someone else bundles.

You suggest that OCL could stop bundling LPG since LPG would appear in the 
SimRel repo automatically.

However OCL still needs to bundle LPG in order for the install from ZIPs 
to work offline. AFAIK there is no SimRel ZIP distribution. If there was, 
it would probably be so big that few would use it. However if there was a 
used-in-SimRel-Orbit ZIP distribution that could be useful and could help 
you enforce limited usage.

Regards

Ed Willink
On 04/02/2016 21:35, David M Williams wrote:
Off the top of my head, I think features are suppose to 'include' them, 
since that is the only way to have a reproducible build or install. If it 
was left up to "requires" then who knows what you would get. 
Granted, there should not be anything breaking, if you simply took a what 
ever was there, within some specified range, but especially with third 
party bundles, you never know. Some are real good at following good 
versioning practices, some are not.  Plus, keep in mind, the "aggregated 
repository" is supposed to be a simple grouping of a subset of what ever 
is in the project repositories. We do not want a situation where if 
someone installs directly from "your" repository, they get one set of 
things, and if they install from the Sim. Release repository they get 
another set of things. Maintenance would be very difficult, then. To 
repeat, that's off the top of my head. Maybe you meant something else. 




From:Alexander Nyßen <nys...@itemis.de>
To:Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:02/04/2016 04:20 PM
Subject:Re: [cross-project-issues-dev] On the issue of building 
with thelatest Orbit repository
Sent by:cross-project-issues-dev-boun...@eclipse.org




Hi David,

could you please clarify why exactly updates would be needed from projects 
because of changes to Orbit bundles? Does it result from the fact that 
Orbit bundles are actually re-bundled by project features? Or from the 
fact that requirements on them are specified too restrictive within 
project bundles or features?

I’m not sure if this is already covered by some simrel reports, but IMHO 
we would be pretty safe if we ensured that

1) no Orbit bundles were actually re-bundled in project features, but only 
required by them, and that
2) dependencies on Orbit bundles or packages would be specified in line 
with the respective Orbit main releases (based on proper version ranges),

becaus

[cross-project-issues-dev] Neon M6 is (finally) available for download.

[David M Williams]

M6 was added to the composite repository at .../releases/neon
which now has M6, M5, and M4. 

And, the EPP packages are available on the "developers tab" of 
Eclipse.org/downloads, specifically, 
https://www.eclipse.org/downloads/index-developer.php
(At the time of writing this, I think there is still one, the Parallel 
Tools package, that is still waiting for confirmation from the package 
maintainer.) 

Several things are worth noting: 

1) BIRT and the EPP Reporting package are not available for M6. From what 
I have heard, they still have every intention of being part of Neon and 
will be "back" for M7. 
This has a ripple effect on MAT, which partially depends on BIRT.  It is 
currently unclear if BIRT being "part of the composite" but not "up to 
date" will have any negative impact for users who try to update (e.g. 
maybe some other components will be "down leveled"?).

2) Speaking of update, you can not update a pre-M6 EPP package to M6. You 
must download a fresh version. The reason is some long term (and much 
requested) improvements required a structural change such that an 'update' 
would no longer work. p2 should prevent the update from occurring, but I 
wanted to mention here to minimize surprises. Spread the word. For 
details, see Bug 332989 and Bug 490515. The much requested improvement is 
the ability to remove or update most features in an EPP package 
independent of the EPP package itself being updated. We hope the community 
can help test this well, between M6 and M7, to be sure all works as 
expected. 

Thanks for everyone's help and patience getting M6 out the door. Now that 
it is ... test well! 


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

[cross-project-issues-dev] New M6 plan -- slipping one day, to Wednesday 3/30 10 AM

[David M Williams]

Given the serious nature of the previously mentioned issues, we have 
decided to re-spin the Sim. Release repo, and EPP packages. 

The new 'staging' repository will not be ready for several more hours, and 
EPP packages should be ready for (re) evaluation Tuesday morning. 

Assuming no other blocking issues are found, we will promote that as the 
M6 delivery on Wednesday, 3/30, approximately 10 AM. 

I will update the following bug at every stage of the process. 
Bug 490550 - Re-spin M6 candidate repository 

Thanks, 





From:   David M Williams/Raleigh/IBM@IBMUS
To: cross-project-issues-dev@eclipse.org, 
Date:   03/28/2016 05:41 PM
Subject:[cross-project-issues-dev] Heads up: we may delay M6 Sim. 
Release again.
Sent by:cross-project-issues-dev-boun...@eclipse.org



A pretty serious issue has been found, where one project (or, the 
interaction of a few) causes some project's M6 content to not be in the 
SIm. Release repository (but instead "back leveled"  at least WTP, or part 
of WTP? to the M5 level). 

For more detail, see 
https://dev.eclipse.org/mhonarc/lists/epp-dev/msg04001.html
and 
https://dev.eclipse.org/mhonarc/lists/epp-dev/msg04002.html

This is still being investigated, and we are waiting to hear back from 
some projects. But I wanted to give a "heads up" since to re-spin (one way 
or another) is the only solution I know of. 

I'll update this list once I know a solid plan, but, in the mean time, I 
will start a "pessimistic" respin, that simply excludes a few projects. 
Ideally, we can get some quick fixes that might make that pessimistic 
respin unnecessary, and then would do another "more correct" respin. 

Stay tuned ... 

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] Heads up: we may delay M6 Sim. Release again.

[David M Williams]

A pretty serious issue has been found, where one project (or, the 
interaction of a few) causes some project's M6 content to not be in the 
SIm. Release repository (but instead "back leveled"  at least WTP, or part 
of WTP? to the M5 level). 

For more detail, see 
https://dev.eclipse.org/mhonarc/lists/epp-dev/msg04001.html
and 
https://dev.eclipse.org/mhonarc/lists/epp-dev/msg04002.html

This is still being investigated, and we are waiting to hear back from 
some projects. But I wanted to give a "heads up" since to re-spin (one way 
or another) is the only solution I know of. 

I'll update this list once I know a solid plan, but, in the mean time, I 
will start a "pessimistic" respin, that simply excludes a few projects. 
Ideally, we can get some quick fixes that might make that pessimistic 
respin unnecessary, and then would do another "more correct" respin. 

Stay tuned ... 

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] Reworked Plan for M6 - release on Tuesday at 10 AM (Eastern)

[David M Williams]

The signing service appears fixed (Bug 489890) so I hope those that were 
having issues getting in their final submissions can now get them in this 
afternoon so that by this evening (Thursday, 3/24, roughly 5 or 7 PM) we 
can declare the staging repository "complete". 

The EPP packages then will be ready -- I am guessing -- first thing Monday 
at the latest, perhaps earlier. 
(Only Markus can say. It depends on how much he is working while on 
vacation :) 

Then to allow some time for sanity checking, maintainers sign-offs, and 
mirroring, we will plan on formally releasing on Tuesday at 10 AM. 

Apologies for the issues and the churn. 




From:   Markus Knauer <mkna...@eclipsesource.com>
To: Cross project issues <cross-project-issues-dev@eclipse.org>, 
Cc: Eclipse Packaging Project <epp-...@eclipse.org>
Date:   03/23/2016 04:50 PM
Subject:Re: [cross-project-issues-dev] [epp-dev] [NEON M6] Eclipse 
Foundation office will be closed on Good Friday
Sent by:cross-project-issues-dev-boun...@eclipse.org



Sounds like the perfect solution to me, highly appreciated... my personal 
opinion is that we should release on Tuesday, i.e. after Easter Monday. I 
hope that'll give us enough time to get enough +1 votes for the packages.

Thanks,
Markus


On 23 March 2016 at 20:40, David M Williams <david_willi...@us.ibm.com> 
wrote:
I have not seen Markus on-line, to check is schedule, but 

I suggest we delay until Monday (3/28) - at least, possibly Tuesday, to 
allow time for creation and adequate testing. I think that would be less 
stressful, higher quality, and give us time to fix the signing service 
(bug 489890). 

I hope that those that can not do it Monday or Tuesday  (due to planned 
vacations, etc.) can find a "back up" person to sign-off on their EPP 
package. 

Given this (and the problems with signing), let's say the Sim. Release 
repo will "freeze" on Thursday night, 5 PM (Eastern) instead of tonight. 

Let us know if anyone anticipates issues with this change in schedule that 
we have not anticipated. 





From:Christopher Guindon <chris.guin...@eclipse.org>
To:epp-...@eclipse.org, 
Date:03/23/2016 02:11 PM
Subject:Re: [epp-dev] [NEON M6] Eclipse Foundation office will be 
closed on Good Friday
Sent by:epp-dev-boun...@eclipse.org




Correction:

10:00am not 10:00pm :)

On 2016-03-23 2:09 PM, Christopher Guindon wrote:
Hi package maintainers,

I noticed today in my calendar that we are releasing Neon M6 on Friday, 
March 25th @ 10:00pm EST.

Unfortunately the Eclipse Foundation office will be closed on Good Friday. 


Can we move the release to tomorrow (Thursday, March 24th @ 10:00pm EST) 
or next Monday (Monday, March 28th @ 10:00pm EST)?


-- 
Christopher Guindon
Lead Web Developer
Eclipse Foundation
Twitter: @chrisguindon




___
epp-dev mailing list
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

-- 
Christopher Guindon
Lead Web Developer
Eclipse Foundation
Twitter: @chrisguindon

___
epp-dev mailing list
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


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Notice of a change in Orbit's retention policy for "active builds"

[David M Williams]

In the past, we Orbit committers thought we should keep "3 versions" of a 
package in "active builds".  But long ago problems with that approach 
became apparent. Now is a good time to change the policy as we are making 
some progress on a new build system. Before we "cut over" (which I expect 
to formally be around the time of the Neon release) we want to have one, 
minimal, pristine p2 repo that was based on the old build technology. But, 
even if we were not doing that new build system, the new policy makes a 
lot more common sense. 

(And, to be clear, this does not change the policy of retraining 
"R-builds" -- as before, those builds are kept "forever".) 

We are changing the policy to keep only one (the latest) version in Orbit 
active builds -- with several known exceptions and most requested 
exceptions. Above all, we do not want to impact anyone in the 
"simultaneous release". And we have good and easy data on what is used 
there. The larger risk is impacting projects that are not part of the 
release train. Those project will need to tell us if they need something 
in active builds (or, they can simply get the older stuff from a previous 
R-builds). 

The written version of the policy is at 
https://wiki.eclipse.org/Orbit/Promotion,_Release,_and_Retention_Policies#Bundle_Retention_in_active_builds


If anyone wants to see the difference between the old policy and the new, 
it is there in Wiki History: 
https://wiki.eclipse.org/index.php?title=Orbit%2FPromotion%2C_Release%2C_and_Retention_Policies=revision=402896=371840

The one exception to what is written is we say "normally old stuff should 
be removed by M6" -- but, we are not making that deadline this year. We 
will be removing a lot of old stuff soon, so that by M7 we should be 
relatively clean and stable.

I have opened the following bug to detail which "active" old bundles will 
be retained and which removed. Please comment there if you have a special 
case that is not obvious. 

Bug 489949 - remove "old stuff" from active builds 

If any specific issues or questions, the best place to ask is in 
Bug 489949 or the orbit-dev list. 

Thanks, 

P.S. If you haven't yet, a good time to be sure to get your Orbit bundles 
from the M6 delivery, so we have a more accurate picture of what is 
required and what is not. That M6 repository is at 
http://download.eclipse.org/tools/orbit/downloads/drops/S20160308060251/repository/



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] properties-maven-plugin breaks somebuilds

[David M Williams]

This should have been "now" as of about 4:10 today (3/20). 
Sorry for the temporary issue. 
I have updated bug 490027 (with a number of "side issues")  but if you are 
still seeing, please comment in that bug 490027. 




From:   Mykola Nikishov 
To: cross-project-issues-dev@eclipse.org, 
Date:   03/20/2016 12:16 PM
Subject:[cross-project-issues-dev] properties-maven-plugin breaks 
somebuilds
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi there,

Some CBI and Equinox p2 builds on Hudson (and in my local environment
as well) are broken because properties-maven-plugin's goal
read-project-properties cannot load properties file:

[INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with
exception(s)
[INFO] o.h.m.e.h.MavenExecutionResultHandler - [1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal 
org.codehaus.mojo:properties-maven-plugin:1.0.0:read-project-properties
(default) on project ie.wombat.jbdiff: Properties could not be loaded
from URL 
file:opt/public/hipp/homes/genie.p2/.m2/build-individual-repository.properties

[DEBUG] Closing connection to remote
[ERROR] Failed to execute goal
org.codehaus.mojo:properties-maven-plugin:1.0.0:read-project-properties
(default) on project ie.wombat.jbdiff: Properties could not be loaded
from URL 
file:opt/public/hipp/homes/genie.p2/.m2/build-individual-repository.properties

-> [Help 1]

I filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=490027 against
Equinox p2. Any ideas?
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] access to lib/ext

[David M Williams]

Others may know "why" it is the case, but one approach is to use a custom 
p2.inf file to add it to the vmargs in eclipse.ini. 
If you do that, though, be sure you only add that specific jar, so you 
don't accidentally change other behavior of the IDE (for example, if there 
was a different version of xalan installed there). 
And, also, be sure you *remove* the argument when the feature is removed 
(via unconfigure). 
Paul Webster has an old blog entry that shows how to do this for a 
different VM argument, if that helps. 
http://pweclipse.blogspot.com/2012_02_01_archive.html

To play it safe, I would file a "works with" CQ. Ideally, you would have 
some other "runtime" available or plugable, in case people use a different 
VM or things change in the future. Or, something like ant does ... where a 
different ant runtime can be specified in preferences. 






From:   "Gorkem Ercan" 
To: "Cross project issues" , 
Date:   03/03/2016 01:18 PM
Subject:[cross-project-issues-dev] access to lib/ext
Sent by:cross-project-issues-dev-boun...@eclipse.org




Hi,
On JSDT project we are trying to utilize nashorn as runtime for 
javascript based tool.
Nashorn is part of JDK8 and is shipped as nashorn.jar on lib/ext folder 
of jdk.

At the moment, it looks like Eclipse does not have access to the jar 
files on the lib/ext folder
of the JDK. Is this by design? Is there a way for a bundle to get 
Eclipse runtime give access to
lib/ext jars?

Thanks,
—
Gorkem
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] OS X application signing

[David M Williams]

I think for the "signFiles" you need *just* the file name. (ICE.app in 
your case). The "place" it is looking for that, is different than your 
"whole build directory". 

cbi-dev is a good list to ask questions like this. 




From:   Greg Watson 
To: cross-project-issues-dev@eclipse.org, 
Date:   03/01/2016 01:50 PM
Subject:[cross-project-issues-dev] OS X application signing
Sent by:cross-project-issues-dev-boun...@eclipse.org



Has anyone been able to get OS X application signing to work?

I added the following to our build:

   
   org.eclipse.cbi.maven.plugins
   eclipse-macsigner-plugin
   ${cbi-plugins.version}
   
   
   
   sign
   
   package
 
  
  
${project.build.directory}/products/ice.product/macosx/cocoa/x86_64/ICE.app
  
 
   
   
   

When the build runs, it says:

[INFO] --- eclipse-macsigner-plugin:1.1.3:sign (default) @ 
org.eclipse.ice.repository ---
[INFO] [Tue Mar 01 12:42:09 EST 2016] Signing OS X application 
'/jobs/genie.ice/ice-next/workspace/ice/org.eclipse.ice.repository/target/products/ice.product/macosx/cocoa/x86_64/ICE.app'...

However, the codesign command says:

$ codesign --verify ICE.app
ICE.app: code object is not signed at all
In architecture: x86_64

Any help or suggestions appreciated.

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




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Mars.2 is now available

[David M Williams]

The update repositories are well mirrored, and, I'm sure, are already 
burning up the bandwidth. 

That is, "check for updates" will now update to Mars.2 from the built-in 
repository of 

http://download.eclipse.org/releases/mars/

Fresh EPP packages are also now available from 

https://www.eclipse.org/downloads/

Greatest thanks to everyone who made this update release available, 
bringing improved quality and some new features to the Mars stream. 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Mars.2 Final Candidate is ready for final testing and release preparation

[David M Williams]

Getting closer! 

The final candidate for Mars.2 is ready for testing and final 
preparations. We are now in the not-so-quite week before the official 
release -- no more builds (for the Mars stream) but there is still work to 
do to be sure we are ready. 

If no horribly blocking bugs found, we are going to release these bits 
next Friday about 10:00 AM (Eastern). 
Before you "make visible" your bits next week, it is best to check this 
list first, just to make sure there is no last minute "Wait! ... " 
messages. 
I am planning to announce here on this list next Friday once Markus and I 
"flip the switch". 

The final candidate EPP packages are not be mirrored or put on 
'downloads', but they can be found at 

https://hudson.eclipse.org/packaging/job/mars.epp-tycho-build/383/artifact/org.eclipse.epp.packages/archive/

Likewise, every participating team should test that "check for updates" 
works as expected, though some special steps are required. To test well, 
you need to disable existing repositories, and add the two that will 
become part of the release next week: 

http://download.eclipse.org/technology/epp/packages/mars/SR2-RC4/
and 
http://download.eclipse.org/releases/maintenance/

Ideally, you would first check updating from Mars.1 to this pre-release 
Mars.2. And then start fresh, and test updating from Mars directly to this 
pre-release Mars.2. And then start fresh and test again with the "old" 
.../releases/mars site enabled -- this last case simulates what it will be 
like next week when we have a larger composite site at .../releases/mars. 

The goal of all our "final week" testing is not so much to find common 
bugs but to make sure there is nothing "blocking" that prevents users from 
updating, or worse, the update appears to work, but then Eclipse no longer 
starts, or other similar issues. In some cases, projects may find a bug 
for which they will want to have a documented workaround ready, per 
perhaps even a feature patch. 

Good luck in your final preparations, 

Thanks as always, 




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Mars.2 staging repository is complete

[David M Williams]

Let's see ... what day is it? It is "done day"! (well, mostly done). All 
code is "in", the EPP packages for Mars.2 will be produced, and we'll 
spend about a week finishing up non-code odds and ends and let artifacts 
mirror before they are made visible. 

And doing some final testing, of course!  If anyone has a truly "blocking" 
bug, feel free to bring it up for consideration for a respin before 
Friday. After that, you can only bring it up if you are feeling really 
really brave. :) 
[Really, just kidding ... we will always be polite and supportive ... even 
if we say "no" to a respin.] 

I am sure everyone remembers we release "simultaneously" on 2/26. (about 
10 AM, Eastern). 

There is no formal "Final Daze" document for Mars.2 but the same 
principles apply. You might re-read 
https://wiki.eclipse.org/Mars/Final_Daze
if you don't recall those principles. 

In particular, the bug to use to update the info center for any modified 
doc bundles is 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=477616

It also helps to check your "mirrorsURL" values are set correctly for your 
final artifacts location. At least visually. Even better to test: 
https://wiki.eclipse.org/Equinox/p2/p2.mirrorsURL 

Greatest thanks as usual! 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] A funny thing happened on the way to Mars.2 -- in Orbit

[David M Williams]

> > This  will only be relevant to you if you use
> > org.apache.httpcomponents.httpclient
> > and exactly version
> > 4.3.6.v201411290715
> We seem to have it in our Oomph repos. I've checked this:
> 
>  estepper@build:~/oomph/drops/release/1.3.0/plugins> jarsigner -
> verify -certs 
> org.apache.httpcomponents.httpclient_4.3.6.v201411290715.jar
>  jar verified.
> 
> So, we're good, right?
> 

Yes, you're good. 

And, to clarify, that is the right version to have in your Mars.2 repos 
(if you use it at all). 

But since there is a "bad" one out there (in Orbit, at least) with the 
same version, I was suggesting to verify if it was in your project 
repositories to make sure you had the good one. 

If it is the good one, you get "jar verified" as above. 

If it is "the bad one" it will be pretty obvious: 

$ jarsigner -verify 
org.apache.httpcomponents.httpclient_4.3.6.v201411290715.jar 
jarsigner: java.lang.SecurityException: SHA1 digest error for 
org/apache/http/client/cache/HttpCacheEntry.class

And, FYI, the code has not been "tampered with" in any "bad" way. It is 
just that since it is not signed correctly so p2 and others will not 
install it. 

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] A funny thing happened on the way to Mars.2 -- in Orbit

[David M Williams]

I just wanted to call everyone's attention to Orbit Bug 487833. 

This  will only be relevant to you if you use 
org.apache.httpcomponents.httpclient
and exactly version
4.3.6.v201411290715

It turns out there are two version of that bundle, with same version and 
qualifier. The only difference is that one is correctly signed, and the 
other is not correctly signed. 

One that is not correctly signed is in two Orbit R-repositories:

 R20151221205849  Mars.2
 R20151118145958  Mars.1 Patches 

By lucky coincidence, the one that is in the Sim. Release repos is the 
correctly signed one (including Mars.2 Sim. Release "maintenance" 
(staging) repository). 

Therefore I am NOT suggesting we "re-spin" Mars.2.  But, I am proposing 
that right after Mars.2, Orbit will declare another R-build that is 
exactly the same as the Mars.2 repo, but with that bundle correctly 
signed. It will have version 4.3.6.v201411290715B  (the 'B' making it 
"higher" than the sometimes-incorrectly-signed one). 

I thought I would mention this now for two reasons: 
A. If anyone has a concrete reason how this plan would cause problems, let 
us know by commenting in Bug 487833. And, 
B. If anyone has this bundle/version your own "project repositories" it 
would be a good time for you verify it is OK, and if not, to decide what 
to do. 
It is easy to check. From the plugins directory of your repository, run 
jarsigner -verify  org.apache.httpcomponents.httpclient_
4.3.6.v201411290715.jar

I am hoping no one else has the issue because for years  we in the Eclipse 
Platform get this bundle from ECF so it is pretty much "everywhere" 
already. 

The problem in Orbit was introduced some time towards the end of last 
year.  It was probably caused in part by some error I made when making an 
Orbit build change, or making that "Patch Build"? 

But another reason for the problem is that a infrastructure's signing 
service does not always work as expect. Sometimes "skipping" a jar that is 
already signed, but sometimes re-signing it again with Java 6.  The reason 
I am guessing that is due to Bug 487087, where ECF is having trouble 
getting that bundle "returned" from signing service correctly (that is, 
correctly untouched).  Any Buckminster Build experts reading this that 
know how to set an environment variable to force Java 8 to be used during 
signing could probably solve that bug for ECF. 

Thanks all, 




 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Mars.2 RC3 is available

[David M Williams]

It is official. 

Mars.2 RC3 is now available for download or update. 

You can download the EPP packages from the following URL: 

https://www.eclipse.org/downloads/index-developer.php?release=mars

(There are about four still waiting for package maintainers to sanity 
check and give their approval on the epp-dev list). 

= = = = = 

To test that "check for updates" works, you need to add the following URLs 
to your software repository lists: 

http://download.eclipse.org/technology/epp/packages/mars/SR2-RC3/
http://download.eclipse.org/releases/maintenance/

= = = = = =

For testing "check for updates" and that "categories" are correct, I 
recommend you start with "Mars" or "Mars.1" and that you disable all other 
repo sites, 
and turn off the preference to "check other sites for dependencies." That 
makes sure you are testing the RC3 site only. 

Assuming that works ok, I think recommend you start over fresh, with all 
sites enabled, and the preference for "other sites" enabled, 
and make sure you get the same results and see the same things in 
'categories.' 

Moreover, don't forget -- you do not have to test only your favorite 
projects -- try installing everything, or, at least, some larger set, and 
make sure everything still works. 

= = = = = = 

It is now past the time I say "test early, test often." Instead, my motto 
for the next few weeks is "test, test, and test again!" :) 
We want to avoid introducing regressions. 

Plus, it helps if you 'verify' bug fixes, especially all the worst ones 
(blocking, critical, major) -- and, also, any new function. 

Thanks as usual for making the improvements to our (final) Mars update 
release possible. 

Best of luck getting your final bits ready. 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Platform's RC4 final candidate will be a bit late

[David M Williams]

Just to keep everyone informed, our declaration of "RC4" will be a bit 
late.  We have started a re-build to fix a regression (see SWT Bug 487687
). The bits themselves should be available this evening about 6 PM 
(Eastern) and will be on our download page as the build named 
M20160212-1500.  But we will not "declare and promote it" as the official 
RC4 candidate after the unit tests run and we can verify the fix is in it 
as expected -- which should be tomorrow (Saturday).

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

Re: [cross-project-issues-dev] On the issue of building withthelatest Orbit repository

[David M Williams]

 > 3. Alternatively, you can create a root feature that includes your 
> actual project feature and the Orbit bundles you require. You point 
> your build at this feature, but you do not contribute this feature 
> to simrel and you do not making it visible in your own categories 
> file. For the cleanest result, you’d remove this feature as a post-
> build step, but it wouldn’t hurt anything if it were to remain as 
> “hidden” feature in your repository that never gets aggregated or 
installed.

I have a lot more to say on the general topic being discussed, but thought 
I'd try to clear up this one point quickly. 

If there is something "in your repository" that you name in your b3aggrcon 
file, then p2 considers anything in there as "fair game" to pull, if it 
satisfies some constraint it is trying to satisfy. 

It may pick something from there rarely, but it has been a "real life" 
problem over the years, where people mistakenly think that only the 
features they name are installed from their repository. Whether not it 
would be a problem depends on many things -- some of which is what other 
projects do or specify, which you could never know or be in control of. 

While some are surprised at this, it is also the way p2 works when a user 
installs something. 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Take your pick! Both Mars.2 RC2 and Neon M5 are both now available for download/update

[David M Williams]

And I hope everyone picks both! 

Congratulations to all who participated in this busy week! 

And, thanks to you, both Mars.2 RC2 and Neon M5 are now available for 
downloading and testing. 

Neon M5 

Update any Neon package from the built-in URL of
 http://download.eclipse.org/releases/neon

The EPP packages are available from
 https://www.eclipse.org/downloads/index-developer.php?release=neon

Mars.2 RC2

To test "check for updates" of already installed EPP packages, you will 
need to have two repositories in your preferences list: 
http://download.eclipse.org/technology/epp/packages/mars/SR2-RC2/
and 
http://download.eclipse.org/releases/maintenance

The EPP packages are available from
https://www.eclipse.org/downloads/index-developer.php?release=mars


Please pass the word to your users and adopters so that a lot of people 
can help us test both of these significant checkpoints. 
We want to catch any regressions or surprises now, while there might be 
time to fix them. 

Thanks again! 




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] On the issue of building with the latest Orbit repository

[David M Williams]

Off the top of my head, I think features are suppose to 'include' them, 
since that is the only way to have a reproducible build or install. If it 
was left up to "requires" then who knows what you would get. 
Granted, there should not be anything breaking, if you simply took a what 
ever was there, within some specified range, but especially with third 
party bundles, you never know. Some are real good at following good 
versioning practices, some are not.  Plus, keep in mind, the "aggregated 
repository" is supposed to be a simple grouping of a subset of what ever 
is in the project repositories. We do not want a situation where if 
someone installs directly from "your" repository, they get one set of 
things, and if they install from the Sim. Release repository they get 
another set of things. Maintenance would be very difficult, then. To 
repeat, that's off the top of my head. Maybe you meant something else. 




From:   Alexander Nyßen <nys...@itemis.de>
To: Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:   02/04/2016 04:20 PM
Subject:Re: [cross-project-issues-dev] On the issue of building 
with thelatest Orbit repository
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi David,

could you please clarify why exactly updates would be needed from projects 
because of changes to Orbit bundles? Does it result from the fact that 
Orbit bundles are actually re-bundled by project features? Or from the 
fact that requirements on them are specified too restrictive within 
project bundles or features?

I’m not sure if this is already covered by some simrel reports, but IMHO 
we would be pretty safe if we ensured that

1) no Orbit bundles were actually re-bundled in project features, but only 
required by them, and that
2) dependencies on Orbit bundles or packages would be specified in line 
with the respective Orbit main releases (based on proper version ranges),

because the aggregation could then pretty much control which Orbit bundles 
get pulled in. If we would in addition impose the same restrictions on 
Orbit releases as on project releases (namely that updates including 
breaking changes are not allowed in maintenance releases), I would assume 
no project should actually have to update its contribution for a 
maintenance release.

Cheers
Alexander

Am 04.02.2016 um 21:43 schrieb Ed Willink <e...@willink.me.uk>:

HI

"commons.collections" doesn't seem that well used. No version of it is my 
workspaces, so QVTd, (Xtext, EGIT, UML, QVTo, OCL) cannot have a 
dependency on it. No re-contribution needed.

    Regards

Ed Willink

On 04/02/2016 20:19, David M Williams wrote:
Ed, 

Thanks for bringing this "no maintenance, no new Orbit" issue to my 
attention. 

While the Planning Council does not like to "make" people do extra work 
they would not normally do, I believe it was the intent of one of our 
requirements [1] that the latest Orbit be consumed every update release -- 
if there has been a new Orbit "released". Most often there is not a new 
Orbit release, since we in Orbit do that only for significant issues. This 
time, it was only for the 'commons.collections' security bug, and a bad 
bug in Ant 1.9.4 that drove us to provide Ant 1.9.6. [2]. 

While I will not say you *have* to update and provide a new build, I would 
encourage you to, as well as anyone else who uses "commons.collections" 
since we don't want to "spread around" a package that has known security 
flaw in it. 

As far as I know, in most cases of installing and updating people will get 
the correct, fixed version of that bundle, but am not positive that is 
always true so I hate for it to be the available from any of our "most 
recent repositories" (Simultaneous Release or not) -- after all, the b3 
aggegator is including it for some reason -- so someone must say they 
require it?  

But I am also not the "security policeman" that will say that bundle must 
be expunged from all current downloads. (If I recall, the security issue 
only applied to specialized cases ... but, if you were running in that 
case, it was a bad security bug possibly leading to a malicious person 
"executing arbitrary commands". 

I have opened bug 487285 to investigate or discuss this issue further. [3] 
And,  I will put this on future Planning Council agendas to see if we can 
word that requirement [1] better so that all projects know better what is 
expected of them.

Thanks again, 

[1] 
https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Re-use_and_share_common_third_party_code_.28partially_tested.29

[2] https://dev.eclipse.org/mhonarc/lists/orbit-dev/msg04419.html
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=487285






From:Ed Willink <e...@willink.me.uk>
To:cross-project-issues-dev@eclipse.org, 
Date:02

Re: [cross-project-issues-dev] Ready for Mars.2 ?

[David M Williams]

The .../download.eclipse.org/releases/mars/201509251000/ 
repo was for that "last minute rebuild" we did for one project. 
(It was going to be THE release, but we ended up releasing on 201510021000 
due to the required re-spin.) 

If you are still "seeing" that in a maintenance branch, then I suspect you 
are looking at Mars_maintenance.1 (which was the branch used for that one 
purpose of the Mars.1 respin.)
The maintenance branch for Mars.1 and Mars.2 is named Mars_maintenance. 

From what I see, Riena is still being built from .../
rt/riena/6.1.0.RC1/e4-rap/. So, if there are "warnings" in the report, I 
suspect they were always there. 

But, if you want to check, the "repo reports" for Mars.1 are available at 
http://download.eclipse.org/releases/mars/201510021000/buildInfo/reporeports/

"keep 'um coming" if there are more questions or comments. 

Thanks, 






From:   Christian Campo <christian.ca...@compeople.de>
To: Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:   02/04/2016 02:48 AM
Subject:Re: [cross-project-issues-dev] Ready for Mars.2 ?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi David,

Another non-sleeping project here :-). The intention of Riena is to 
contribute exactly what we contributed to Mars itself. Every contribution 
file changed ? I didnt change the Riena contribution file but I noticed 
that YOU did.

You changed the contribution for Riena from 
http://download.eclipse.org/rt/riena/6.1.0.RC1/e4-rap/
To http://download.eclipse.org/releases/mars/201509251000/

I am pretty sure that the simrel reports where clean for Mars for Riena. 
Now it is complaining about all sort of things. One is that there are no 
pack200 files. Fact is that the original URL contains pack200 files, while 
the release location does not.

What was the intention of changing the URL in Riena’s contribution ? 
Should I change it back ?

Let me know what the next steps should be….

christian

Von: <cross-project-issues-dev-boun...@eclipse.org> on behalf of Alexander 
Nyßen <nys...@itemis.de>
Antworten an: Cross issues <cross-project-issues-dev@eclipse.org>
Datum: Donnerstag, 4. Februar 2016 um 08:29
An: Cross issues <cross-project-issues-dev@eclipse.org>
Betreff: Re: [cross-project-issues-dev] Ready for Mars.2 ?

Hi David,

I was wondering about your first statement also, as GEF is not 
contributing something new to Mars.2 either (we are fully concentrating on 
our 4.0.0 release for Neon). Our contribution to Mars.2 should be the same 
as that to Mars, and as far as I can see that is indeed the case. 

Regards
Alexander

Am 04.02.2016 um 07:08 schrieb Ed Willink <e...@willink.me.uk>:

Hi David

On 03/02/2016 22:29, David M Williams wrote:
- Every contribution file has changed since Mars.1. Also good. (i.e. no 
projects are just sleeping and forgot to update :) 

You might want to review your query. qvtd.b3aggrcon was last changed by me 
on 26 June, and by you on 14 July.

We are certainly not sleeping, and did not forget to update. Just working 
very hard to support the functionality required for graduation to 1.0.0.
And ... worst of all, IMHO, some "old" third party jars are still being 
used, which implies to me someone is not using the latest version of Orbit 
(R20151221205849). 
But if a project has no maintenance to contribute, I thought no 
rebuild/contribution was required and so of course an old Orbit would be 
in use. (I don't think that QVTd imposes tight bounds on Orbit 
contributions.)

Regards

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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino



-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery 

[cross-project-issues-dev] Neon+1 == Oxygen

[David M Williams]

Perhaps I am was the last to know ... but, for anyone else that does not 
closely follow the right bugs or twitter feeds (like me) the name of the 
2017 Simultaneous Release (aka Neon+1) has been chosen to be Oxygen! 
(Well, normally without the exclamation point. :) 

Thank you to all who voted and thank you to the Eclipse Foundation for 
their process help and thank you to Chris Aniszczyk for coordinating the 
effort. 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] On the issue of building with the latest Orbit repository

[David M Williams]

Ed, 

Thanks for bringing this "no maintenance, no new Orbit" issue to my 
attention. 

While the Planning Council does not like to "make" people do extra work 
they would not normally do, I believe it was the intent of one of our 
requirements [1] that the latest Orbit be consumed every update release -- 
if there has been a new Orbit "released". Most often there is not a new 
Orbit release, since we in Orbit do that only for significant issues. This 
time, it was only for the 'commons.collections' security bug, and a bad 
bug in Ant 1.9.4 that drove us to provide Ant 1.9.6. [2]. 

While I will not say you *have* to update and provide a new build, I would 
encourage you to, as well as anyone else who uses "commons.collections" 
since we don't want to "spread around" a package that has known security 
flaw in it. 

As far as I know, in most cases of installing and updating people will get 
the correct, fixed version of that bundle, but am not positive that is 
always true so I hate for it to be the available from any of our "most 
recent repositories" (Simultaneous Release or not) -- after all, the b3 
aggegator is including it for some reason -- so someone must say they 
require it? 

But I am also not the "security policeman" that will say that bundle must 
be expunged from all current downloads. (If I recall, the security issue 
only applied to specialized cases ... but, if you were running in that 
case, it was a bad security bug possibly leading to a malicious person 
"executing arbitrary commands". 

I have opened bug 487285 to investigate or discuss this issue further. [3] 
And,  I will put this on future Planning Council agendas to see if we can 
word that requirement [1] better so that all projects know better what is 
expected of them.

Thanks again, 

[1] 
https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Re-use_and_share_common_third_party_code_.28partially_tested.29
[2] https://dev.eclipse.org/mhonarc/lists/orbit-dev/msg04419.html
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=487285






From:   Ed Willink <e...@willink.me.uk>
To: cross-project-issues-dev@eclipse.org, 
Date:   02/04/2016 01:12 AM
Subject:Re: [cross-project-issues-dev] Ready for Mars.2 ?
Sent by:    cross-project-issues-dev-boun...@eclipse.org



Hi David

On 03/02/2016 22:29, David M Williams wrote:
- Every contribution file has changed since Mars.1. Also good. (i.e. no 
projects are just sleeping and forgot to update :) 

You might want to review your query. qvtd.b3aggrcon was last changed by me 
on 26 June, and by you on 14 July.

We are certainly not sleeping, and did not forget to update. Just working 
very hard to support the functionality required for graduation to 1.0.0.
And ... worst of all, IMHO, some "old" third party jars are still being 
used, which implies to me someone is not using the latest version of Orbit 
(R20151221205849). 
But if a project has no maintenance to contribute, I thought no 
rebuild/contribution was required and so of course an old Orbit would be 
in use. (I don't think that QVTd imposes tight bounds on Orbit 
contributions.)

Regards

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


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

Re: [cross-project-issues-dev] Ready for Mars.2 ?

[David M Williams]

Thanks to all to pointing out that I was making an incorrect statement 
about "all files changed". 
I made two errors: First, I forgot that we did a special rebuild, for 
someone, so the "very last build" had a set of URL's that were not 
original, but pointed to "what we had already", while we rebuilt for that 
one project. 
If I correct for that, there were about 45 files that changed -- really, 
35 projects did not change at all? Lucky you! But that is a lot of 
"sleepers". :) 
Just kidding about project's sleeping. What I was *trying* to do was see 
if any projects were basically "defunct" ... or had really "lost 
communication" with the Train's dates ... but turns out that I can not do 
that by looking at the files. 

My second mistake (sort of) was counting "any change" as a change, whereas 
some them, such as GEF, were simply to change their URL to their permanent 
one, but no actual change in content. So, that might mean even fewer than 
45 did, but, as some used to remind me, some project's have their 
b3aggrcon files specified so loose, they could change their content a lot, 
and never change the file, so looking at the file is a bad idea all the 
way around. [That is, one reason why we "changed the rule" so that the 
files need to be more specific for Neon]. 

Apologies for the noise that minor comment made -- but I learned (or, was 
reminded) of a lot. 





From:   Alexander Nyßen <nys...@itemis.de>
To: Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:   02/04/2016 02:29 AM
Subject:Re: [cross-project-issues-dev] Ready for Mars.2 ?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi David,

I was wondering about your first statement also, as GEF is not 
contributing something new to Mars.2 either (we are fully concentrating on 
our 4.0.0 release for Neon). Our contribution to Mars.2 should be the same 
as that to Mars, and as far as I can see that is indeed the case. 

Regards
Alexander

Am 04.02.2016 um 07:08 schrieb Ed Willink <e...@willink.me.uk>:

Hi David

On 03/02/2016 22:29, David M Williams wrote:
- Every contribution file has changed since Mars.1. Also good. (i.e. no 
projects are just sleeping and forgot to update :) 

You might want to review your query. qvtd.b3aggrcon was last changed by me 
on 26 June, and by you on 14 July.

We are certainly not sleeping, and did not forget to update. Just working 
very hard to support the functionality required for graduation to 1.0.0.
And ... worst of all, IMHO, some "old" third party jars are still being 
used, which implies to me someone is not using the latest version of Orbit 
(R20151221205849). 
But if a project has no maintenance to contribute, I thought no 
rebuild/contribution was required and so of course an old Orbit would be 
in use. (I don't think that QVTd imposes tight bounds on Orbit 
contributions.)

Regards

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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino


[attachment "signature.asc" deleted by David M Williams/Raleigh/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

[cross-project-issues-dev] Ready for Mars.2 ?

[David M Williams]

I am sure everyone knows that "now" is the deadline for RC2 submissions so 
I am not asking for anymore changes "now", but I recently took a look at 
the 'input' and 'repository reports' and will highlight a few findings. 

- Everyone is enabled! That's good. 
- Every contribution file has changed since Mars.1. Also good. (i.e. no 
projects are just sleeping and forgot to update :) 

But looking at the repo reports, at 

https://hudson.eclipse.org/simrel/job/simrel.mars.runaggregator.BUILD__CLEAN/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/index.html

I see a few issues that need to be addressed before the release (if they 
have not been already): 

- A number of bundles are missing "legal files" 

https://hudson.eclipse.org/simrel/job/simrel.mars.runaggregator.BUILD__CLEAN/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/reports/layoutCheck.txt

- Even a feature! (which seems rare, for us, to be missing completely)

https://hudson.eclipse.org/simrel/job/simrel.mars.runaggregator.BUILD__CLEAN/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/reports/licenseConsistency.html
[note the %license printed for o.e.bpmn2.modeler.runtime.jboss?] 

And ... worst of all, IMHO, some "old" third party jars are still being 
used, which implies to me someone is not using the latest version of Orbit 
(R20151221205849). 

https://hudson.eclipse.org/simrel/job/simrel.mars.runaggregator.BUILD__CLEAN/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt

Notice that someone is using org.apache.commons.collections  version 
3.2.0. But it is not even in Orbit -- any longer -- because it had a 
security issue fixed in version 3.2.2. PLEASE update for RC3!

There are certainly other "problems" in the reports, but those above, to 
me, are the worst. 

But, overall, things are looking pretty good! 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] Ready for Neon M5?

[David M Williams]

It has been a busy week, eh? 

As with Mars.2 RC2, things are looking fairly good, but more work needed 
than in Mars stream before the Neon release (not too surprisingly). 

I see all repositories and features are 'enabled', that's good. 

I see two new projects contributing (based on b3aggrcon files): 

andmore
egerrit

And two files removed: 

gyrex (still participating in release, just not in the repository)
scout-rap

I hope that "sounds right" to everyone. 

I would have sworn I saw more than "two new projects" declare their intent 
to participate, but have not gone back to look. 

Project leads and release engineers should be sure to frequently check the 
repository reports, such as at 
https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.BUILD__CLEAN/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/index.html

Things are a little worse in terms of bundles missing legal files, bundles 
that are not signed, etc. I hope all those can be fixed "early", such as 
in M6 (they should be correct every build!) 

= = = = 

As usual, later tonight I will send out a note when the repositories are 
"done" for this week (there are still some builds running). 

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] Eclipse Platform's final, official contribution to Neon M5 and Mars.2 RC2 will be a day late

[David M Williams]

Extended team, 

The Platform's final, official contribution to the Sim. Release will be a 
day late. 

Our current candidates are M20160128-1800 (for Mars) and I20160128-2000 
(for Neon). Those doing their own builds for these check points should be 
able to safely use those while doing your own "compiles". Our issue is 
more related to which EMF version to use and package with our downloads. 

The issue is described in bug 486804 [1].  The issue is still be 
investigated, but as of now, we do not know if it is a regression in EMF, 
or a "test-only" problem in our Unit tests. And, in the worst case, even 
if our tests were making some incorrect assumption related to 'order' or 
iteraters, we might be making the same incorrect assumption in our runtime 
code? While it continues to be investigated, we are going to do a "back 
up" build that has the latest EMF version reverted, just in case that 
turns out to be the better version to use at this point in time. The goal 
is that by the time that build is ready (or before :) we will understand 
the root problem completely. 
But in any case, we do not expect the issue to be resolved until very late 
today or tomorrow, on Saturday. 

Thanks, 

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



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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 Platform's final, official contribution to Neon M5 and Mars.2 RC2 will be a day late

[David M Williams]

Never mind. Thanks to Brian de Alwis the problem has been determined to be 
in our Unit tests (and deep, private code that is no longer used). 

I will be working on promoting our final official builds over the next 
couple of hours. 

Thanks, 




From:   David M Williams/Raleigh/IBM@IBMUS
To: cross-project-issues-dev@eclipse.org, 
Date:   01/29/2016 01:40 PM
Subject:[cross-project-issues-dev] Eclipse Platform's final, 
official contribution to Neon M5 and Mars.2 RC2 will be a day late
Sent by:cross-project-issues-dev-boun...@eclipse.org



Extended team, 

The Platform's final, official contribution to the Sim. Release will be a 
day late. 

Our current candidates are M20160128-1800 (for Mars) and I20160128-2000 
(for Neon). Those doing their own builds for these check points should be 
able to safely use those while doing your own "compiles". Our issue is 
more related to which EMF version to use and package with our downloads. 

The issue is described in bug 486804 [1].  The issue is still be 
investigated, but as of now, we do not know if it is a regression in EMF, 
or a "test-only" problem in our Unit tests. And, in the worst case, even 
if our tests were making some incorrect assumption related to 'order' or 
iteraters, we might be making the same incorrect assumption in our runtime 
code? While it continues to be investigated, we are going to do a "back 
up" build that has the latest EMF version reverted, just in case that 
turns out to be the better version to use at this point in time. The goal 
is that by the time that build is ready (or before :) we will understand 
the root problem completely. 
But in any case, we do not expect the issue to be resolved until very late 
today or tomorrow, on Saturday. 

Thanks, 

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

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Mars.2 RC1 warm-up is complete - aggregation jobs re-enabled

[David M Williams]

Yes, sure! We start "now" on RC2 and (for the last time ever :) we still 
have a two week window for RC2 so all input for RC2 is due Feb. 3. But, 
please, everyone, do not wait until Feb. 3rd to submit ... you can always 
contribute something soon, and then contribute again before Feb. 3rd if 
you find you need to. 

Technically, for anyone doing a 'minor' release in Mars.2 (or, a new 
project) you should have already had "the new stuff" in RC1, though bug 
fixes certainly still OK.  If anything deviates from that please read the 
rules in the "plan" for what the rules are and the exception process. 

For details on Mars.2 plan, see 
https://wiki.eclipse.org/Mars/Simultaneous_Release_Plan#Mars.2

Thanks, 




From:   Bob Brodt <bbr...@redhat.com>
To: Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:   01/22/2016 08:42 AM
Subject:Re: [cross-project-issues-dev] Mars.2 RC1 warm-up is 
complete - aggregation jobs re-enabled
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi David,

I would like to get a new service release for BPMN2 Modeler into Mars RC2. 
Does this mean there is still time for another RC2 build?

Cheers,
Bob

On Thu, Jan 21, 2016 at 11:22 PM, David M Williams <
david_willi...@us.ibm.com> wrote:
I am announcing this a bit early because part of the weather forecast for 
central North Carolina on Friday is "freezing rain" which often leads to 
power outages. While I do have a few hours of emergency backup power (and 
a back up internet connection) I just do not want to have to worry about 
getting this announcement out later today. It is, after all, an historic 
announcement! (Tangent below.) 

= = = = = = = 

I suspect everyone knows this is considered a "warm-up" RC, not a true 
candidate for release. That partially means it has not been tested as much 
and partially that there are still "known fixes" to go into some project's 
builds. But, from here on (for RC2, 3 and 4) please make each of them as 
solid as possible and a true candidate for release. (i.e. don't plan on 
waiting until RC4 to put in some big fix ... after all, there might be 
another ice storm somewhere by then and we'll have to release RC3!  :) 
 Very unlikely to happen, but that should be our attitude. 

As with past "warm-up" RCs, we do not publish the EPP packages to the 
downloads page (on developers-index tab), but if you do want to test one, 
you can get it directly from EPP's build archives: 

Downloads of the packages:
https://hudson.eclipse.org/packaging/job/mars.epp-tycho-build/325/artifact/org.eclipse.epp.packages/archive/


p2 repositories (for testing "check for updates") 
https://hudson.eclipse.org/packaging/job/mars.epp-tycho-build/325/artifact/org.eclipse.epp.packages/archive/repository/
and http://download.eclipse.org/releases/maintenance/

Greatest thanks to everyone working on Mars.2. 

= = = = = = = 

What is so historic about this warm-up RC? 

This is our last warm-up RC build -- forever!  For Neon update releases we 
are not planning to have warm-up RCs but going straight to RCs with only 
one week in between. We will still have 4 RCs, though. 

This is partially because we are having 3 update releases during the year, 
instead of 2, so the schedule is a little compressed. 

But, even more so, it is because the vast majority of you Eclipse projects 
are really getting good at this and there seems to be no need for a 
warm-up any longer. We say "go" you put out a release. Job well done! 
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



-- 

Robert ("Bob") Brodt
Senior Software Engineer
JBoss by Red Hat

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Mars.2 RC1 warm-up is complete - aggregation jobs re-enabled

[David M Williams]

Yes, Mars_maintenance is the branch for all Mars.2 updated b3aggrcon 
files. 



From:   Bob Brodt <bbr...@redhat.com>
To: Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:   01/22/2016 09:58 AM
Subject:Re: [cross-project-issues-dev] Mars.2 RC1 warm-up is 
complete - aggregation jobs re-enabled
Sent by:cross-project-issues-dev-boun...@eclipse.org



Good news, thanks. Just a dumb question: I assume we're using the 
Mars_maintenance branch for this RC2?

On Fri, Jan 22, 2016 at 7:06 AM, David M Williams <
david_willi...@us.ibm.com> wrote:
Yes, sure! We start "now" on RC2 and (for the last time ever :) we still 
have a two week window for RC2 so all input for RC2 is due Feb. 3. But, 
please, everyone, do not wait until Feb. 3rd to submit ... you can always 
contribute something soon, and then contribute again before Feb. 3rd if 
you find you need to. 

Technically, for anyone doing a 'minor' release in Mars.2 (or, a new 
project) you should have already had "the new stuff" in RC1, though bug 
fixes certainly still OK.  If anything deviates from that please read the 
rules in the "plan" for what the rules are and the exception process.  

For details on Mars.2 plan, see 
https://wiki.eclipse.org/Mars/Simultaneous_Release_Plan#Mars.2

Thanks, 




From:Bob Brodt <bbr...@redhat.com>
To:Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:01/22/2016 08:42 AM
Subject:Re: [cross-project-issues-dev] Mars.2 RC1 warm-up is 
complete - aggregation jobs re-enabled
Sent by:cross-project-issues-dev-boun...@eclipse.org




Hi David,

I would like to get a new service release for BPMN2 Modeler into Mars RC2. 
Does this mean there is still time for another RC2 build?

Cheers,
Bob

On Thu, Jan 21, 2016 at 11:22 PM, David M Williams <
david_willi...@us.ibm.com> wrote:
I am announcing this a bit early because part of the weather forecast for 
central North Carolina on Friday is "freezing rain" which often leads to 
power outages. While I do have a few hours of emergency backup power (and 
a back up internet connection) I just do not want to have to worry about 
getting this announcement out later today. It is, after all, an historic 
announcement! (Tangent below.) 

= = = = = = = 

I suspect everyone knows this is considered a "warm-up" RC, not a true 
candidate for release. That partially means it has not been tested as much 
and partially that there are still "known fixes" to go into some project's 
builds. But, from here on (for RC2, 3 and 4) please make each of them as 
solid as possible and a true candidate for release. (i.e. don't plan on 
waiting until RC4 to put in some big fix ... after all, there might be 
another ice storm somewhere by then and we'll have to release RC3!  :) 
 Very unlikely to happen, but that should be our attitude. 

As with past "warm-up" RCs, we do not publish the EPP packages to the 
downloads page (on developers-index tab), but if you do want to test one, 
you can get it directly from EPP's build archives: 

Downloads of the packages:
https://hudson.eclipse.org/packaging/job/mars.epp-tycho-build/325/artifact/org.eclipse.epp.packages/archive/


p2 repositories (for testing "check for updates") 
https://hudson.eclipse.org/packaging/job/mars.epp-tycho-build/325/artifact/org.eclipse.epp.packages/archive/repository/
and http://download.eclipse.org/releases/maintenance/

Greatest thanks to everyone working on Mars.2. 

= = = = = = = 

What is so historic about this warm-up RC? 

This is our last warm-up RC build -- forever!  For Neon update releases we 
are not planning to have warm-up RCs but going straight to RCs with only 
one week in between. We will still have 4 RCs, though. 

This is partially because we are having 3 update releases during the year, 
instead of 2, so the schedule is a little compressed. 

But, even more so, it is because the vast majority of you Eclipse projects 
are really getting good at this and there seems to be no need for a 
warm-up any longer. We say "go" you put out a release. Job well done! 
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



-- 

Robert ("Bob") Brodt
Senior Software Engineer
JBoss by Red Hat

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

[cross-project-issues-dev] Fw: Mars.2 RC1 repository is complete

[David M Williams]

First try did not go through. Am retrying now that bug 486216has been 
fixed. 

- Forwarded by David M Williams/Raleigh/IBM on 01/21/2016 10:25 AM 
-

From:   David M Williams/Raleigh/IBM
To: cross-project-issues-dev@eclipse.org, 
Date:   01/21/2016 12:46 AM
Subject:Mars.2 RC1 repository is complete


That is the repository at 
http://download.eclipse.org/releases/maintenance/

I will leave aggegator validation job disabled until Friday to avoid 
confusion while producing the EPP packages. 

While this is technically a "warm up" RC, I would encourage everyone to 
sanity check the repo and make sure things are as you expect. 

And keep in mind that in two weeks, when RC2 is due, Neon M5 is also due. 
So, busy week! Please plan ahead. 

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] Mars.2 RC1 repository is complete

[David M Williams]

That is the repository at 
http://download.eclipse.org/releases/maintenance/

I will leave aggegator validation job disabled until Friday to avoid 
confusion while producing the EPP packages. 

While this is technically a "warm up" RC, I would encourage everyone to 
sanity check the repo and make sure things are as you expect. 

And keep in mind that in two weeks, when RC2 is due, Neon M5 is also due. 
So, busy week! Please plan ahead. 

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] Sim Release aggregation jobs have been re-enabled

[David M Williams]

It appears bug 486076  has been fixed, and I have re-enabled the 
aggregation jobs. 

If anyone will not be able to make the schedule for RC1 warm-up (input due 
tomorrow) based on this 24 delay feel free to say and we can decide if 
better to adjust schedule ... or some other option. 

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

Re: [cross-project-issues-dev] Sorry (again) for the spam of "[marsAggregation] Failed for build ... "

[David M Williams]

Apologies again. From reading the bug it sounded "fixed", but is not. I 
did try turn off mail notification but forgot I have to wipe the workspace 
for that to take effect. So once again, 78 erroneous mail messages were 
sent for "build failed". [If it is any consolation, I did open a "bug on 
myself" to automatically avoid "mass mailings" from the aggregator (
Bug 486078).





From:   David M Williams/Raleigh/IBM@IBMUS
To: cross-project-issues-dev@eclipse.org, 
Date:   01/18/2016 11:23 PM
Subject:[cross-project-issues-dev] Sorry for the spam of 
"[marsAggregation]  Failed for build 2016-01-18_23-05-16"
Sent by:cross-project-issues-dev-boun...@eclipse.org



EVERYONE got a "FAILED BUILD" message tonight (if not more than one). The 
issue is being tracked in 

Bug 486076- Sim release HIPP Instance lost file access to "archives" and 
"downloads" 

In the meantime, I have disabled all "Sim Release" jobs so that it will 
not happen again. 

I know we are at the end of RC1 +1 day, but I hope everyone can recover 
once things start working again on Tuesday. 

Thanks for your patience. 

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

[David M Williams]

Actually, there was yet another thing I should have mentioned. This topic 
of "improve input to the aggregation build" has been discussed in bug 
419746. 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=419746

I suggest further discussion on this topic or this new requirement take 
place there. 

Thanks 




From:   David M Williams/Raleigh/IBM@IBMUS
To: step...@esc-net.de, Cross project issues 
<cross-project-issues-dev@eclipse.org>, 
Date:   01/08/2016 02:04 PM
Subject:Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?
Sent by:cross-project-issues-dev-boun...@eclipse.org



I think this topic has been well discussed, but thought I would add one 
thing since no one has commented on it. 

It is not just listing exact versions and/or pointing to a simple 
repository -- but also that "the b3aggrcon file must change for every new 
contribution". In other words, the requirement would not be satisfied by 
someone merely pointing a simple repository such as "latest". Even if it 
had only "one version" of each feature and bundle, this is one of the 
cases of "changing repository contents in the middle of a build" that we 
are going to avoid. 

Even if no "perfect test" for it, in the long run, we may implement our 
process such that "if the file does not change, we use the contents we 
already have" and won't even look at the source repository and would never 
get new contributions, if someone was pointing at "one repository" and not 
changing the file to point to a unique, simple repository that had their 
intended contribution. 

I just wanted to be clear on this aspect of the requirement, as part of 
"educating everyone". 

= = == = =

Some have mentioned "tools", and a change to b3 aggegator editor might 
indeed be handy. But what others would want even more is something more 
"batch oriented" so that they could produce the input file has part of 
their build (based on a "template", say, that could be their previous 
input?).  And then they may or may not "check in" that new file (to Gerrit 
"for master" :),  based on if that build was declared "good" or not. If 
anyone has any tools like this to share, feel free to do so! I recommend 
getting started by opening a c-p bug and attaching the tool, and then 
others could review and improve if needed. 

= = = = = =  

Thanks, 



 



From:Eike Stepper <steppe...@arcor.de>
To:cross-project-issues-dev@eclipse.org, 
Date:01/08/2016 01:14 PM
Subject:Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Am 08.01.2016 um 17:29 schrieb Marc Khouzam:
> I also would not like to have to change versions.
> Changing the URL only allows me to change one line quickly.
> Changing each version of each feature group is more work and more error 
prone.
Exactly. I also don't want to look *into* my repos for each contribution 
and copy multiple versions around.

Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



>
> And when speaking about tests, isn't it possible to verify that each URL 
is not a composite repo?
>
> 

> *From:* cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of 
> Mickael Istria [mist...@redhat.com]
> *Sent:* January 8, 2016 11:23 AM
> *To:* cross-project-issues-dev@eclipse.org
> *Subject:* Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?
>
> On 01/08/2016 05:15 PM, Eike Stepper wrote:
>> I may misunderstand this fixed version stuff, so I better ask 
explicitely. I will not be forced to author exact 
>> feature versions in my contribution files, right?
>> I'm fine with the rule of contributing only fixed content, but I prefer 
to achieve that goal with non-changing repos.
>
> The rule currently accepts version ranges with "changing" repository 
URL. However, it seems very difficult to write 
> good tests that guarantee that the rule is respected... That's why I'm 
trying to push towards the 4-digits version 
> rule as "de-facto standard", since it can trivially be checked.
> From your contributor point-of-view, what makes changing the version 
more difficult that changing an URL? In any case, 
> you'll have to make a change in the b3aggrcon file whenever you want to 
contribute something new. It seems to me that 
> the extra-cost of changing the version when also changing the URL is not 
that high, is it?
>
> Cheers,
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <

Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?

[David M Williams]

I think this topic has been well discussed, but thought I would add one 
thing since no one has commented on it. 

It is not just listing exact versions and/or pointing to a simple 
repository -- but also that "the b3aggrcon file must change for every new 
contribution". In other words, the requirement would not be satisfied by 
someone merely pointing a simple repository such as "latest". Even if it 
had only "one version" of each feature and bundle, this is one of the 
cases of "changing repository contents in the middle of a build" that we 
are going to avoid. 

Even if no "perfect test" for it, in the long run, we may implement our 
process such that "if the file does not change, we use the contents we 
already have" and won't even look at the source repository and would never 
get new contributions, if someone was pointing at "one repository" and not 
changing the file to point to a unique, simple repository that had their 
intended contribution. 

I just wanted to be clear on this aspect of the requirement, as part of 
"educating everyone". 

= = == = =

Some have mentioned "tools", and a change to b3 aggegator editor might 
indeed be handy. But what others would want even more is something more 
"batch oriented" so that they could produce the input file has part of 
their build (based on a "template", say, that could be their previous 
input?).  And then they may or may not "check in" that new file (to Gerrit 
"for master" :),  based on if that build was declared "good" or not. If 
anyone has any tools like this to share, feel free to do so! I recommend 
getting started by opening a c-p bug and attaching the tool, and then 
others could review and improve if needed. 

= = = = = = 

Thanks, 



 



From:   Eike Stepper 
To: cross-project-issues-dev@eclipse.org, 
Date:   01/08/2016 01:14 PM
Subject:Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Am 08.01.2016 um 17:29 schrieb Marc Khouzam:
> I also would not like to have to change versions.
> Changing the URL only allows me to change one line quickly.
> Changing each version of each feature group is more work and more error 
prone.
Exactly. I also don't want to look *into* my repos for each contribution 
and copy multiple versions around.

Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



>
> And when speaking about tests, isn't it possible to verify that each URL 
is not a composite repo?
>
> 

> *From:* cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of 
> Mickael Istria [mist...@redhat.com]
> *Sent:* January 8, 2016 11:23 AM
> *To:* cross-project-issues-dev@eclipse.org
> *Subject:* Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?
>
> On 01/08/2016 05:15 PM, Eike Stepper wrote:
>> I may misunderstand this fixed version stuff, so I better ask 
explicitely. I will not be forced to author exact 
>> feature versions in my contribution files, right?
>> I'm fine with the rule of contributing only fixed content, but I prefer 
to achieve that goal with non-changing repos.
>
> The rule currently accepts version ranges with "changing" repository 
URL. However, it seems very difficult to write 
> good tests that guarantee that the rule is respected... That's why I'm 
trying to push towards the 4-digits version 
> rule as "de-facto standard", since it can trivially be checked.
> From your contributor point-of-view, what makes changing the version 
more difficult that changing an URL? In any case, 
> you'll have to make a change in the b3aggrcon file whenever you want to 
contribute something new. It seems to me that 
> the extra-cost of changing the version when also changing the URL is not 
that high, is it?
>
> Cheers,
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat 
> My blog  - My Tweets <
http://twitter.com/mickaelistria>
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


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

Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?

[David M Williams]

Honest, I had not seen Sam's question before my latest posting ... guess I 
could have waited a little longer. But I hope my "pre" response in 
https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg12901.html 

answers the question. 





From:   Sam Davis 
To: Cross project issues , 
Date:   01/08/2016 01:57 PM
Subject:Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?
Sent by:cross-project-issues-dev-boun...@eclipse.org



On Fri, Jan 8, 2016 at 8:36 AM, Mickael Istria  wrote:
It would be possible, but checking that a repo isn't a composite doesn't 
validate that its content are immutable. Some repositories contributed 
have their content growing (cumulative build output) and some others have 
content overwritten by newer build.

If a fully qualified version is not specified, is the requirement that the 
repository be immutable, or simply that it only contain one version of 
each feature at a time? In other words, is it ok to update versions by 
just replacing the content of the repository? It's not clear to me from 
reading 
https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Integrate_Early_and_Often


In any case, for Mylyn, I am considering updating our build job so that it 
will push a change to Gerrit to update the qualifiers in our b3aggrcon 
file. Then all we would need to do after a build runs is approve the 
change.___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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: Is the b3 Aggregator Editorbroken?

[David M Williams]

I am not seeing that problem now, but have seen that problem before, but 
only when using "old" versions of the tools. What "base" do you use? I've 
had good luck running it on Mars, but officially Luna (4.4.2) is the 
official version to run it on. Anything earlier, or later than that might 
cause problems. So ... which "platform base" do you use? (with matching 
EMF version, of course). 

I too use 
http://download.eclipse.org/modeling/emft/b3/updates-4.4/

And my version of b3 Aggregator Editor and Engine appear to match yours: 
  b3 Aggregator Editor (Incubation) 0.3.0.v20140928-0617 
org.eclipse.b3.aggregator.editor.feature.feature.group  Eclipse b3 Project
  b3 Aggregator Engine (Incubation) 0.3.0.v20140928-0617 
org.eclipse.b3.aggregator.engine.feature.feature.group  Eclipse b3 Project





From:   Eike Stepper 
To: cross-project-issues-dev@eclipse.org, 
Date:   01/08/2016 02:42 AM
Subject:[cross-project-issues-dev] Simrel: Is the b3 Aggregator 
Editor  broken?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi,

Today I wanted to look at our .b3aggrcon Simrel file, but the editor opens 
an error dialog and finally an editor with an 
error message:

java.lang.RuntimeException: Deprecated resource was not transformed
 at 
org.eclipse.b3.aggregator.presentation.AggregatorEditor.createModel(AggregatorEditor.java:1055)
 at 
org.eclipse.b3.aggregator.presentation.AggregatorEditor.createPagesGen(AggregatorEditor.java:1165)
 at 
org.eclipse.b3.aggregator.presentation.AggregatorEditor.createPages(AggregatorEditor.java:1106)
 at 
org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:363)
 at 
org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPartControl(CompatibilityPart.java:151)
 at 
org.eclipse.ui.internal.e4.compatibility.CompatibilityEditor.createPartControl(CompatibilityEditor.java:99)
 at 
org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:341)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at 
org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
 at 
org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:966)
 at 
org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:931)
 at 
org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:151)
 at 
org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:375)
 at 
org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:294)
 at 
org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
 at 
org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:105)
 at 
org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:74)
 at 
org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:56)
 at 
org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer.createWidget(ContributedPartRenderer.java:129)
 at 
org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:976)
 at 
org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:652)
 at 
org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:758)
 at 
org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$0(PartRenderingEngine.java:729)
 at 
org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:723)
 at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
 at 
org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:707)
 at 
org.eclipse.e4.ui.internal.workbench.PartServiceImpl$1.handleEvent(PartServiceImpl.java:99)
 at 
org.eclipse.e4.ui.services.internal.events.UIEventHandler$1.run(UIEventHandler.java:40)
 at 
org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:234)
 at 
org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:145)
 at org.eclipse.swt.widgets.Display.syncExec(Display.java:4772)
 at 
org.eclipse.e4.ui.internal.workbench.swt.E4Application$1.syncExec(E4Application.java:211)
 at 
org.eclipse.e4.ui.services.internal.events.UIEventHandler.handleEvent(UIEventHandler.java:36)
 at 
org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:201)
 at 

Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?

[David M Williams]

I would not say "stability/quality" has improved (depending on what that 
means), but it is clear that it avoids "breaking HEAD" of the 
'simrel.build' repository. And that is great. 

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

But I myself would not like to see it *required* to go through 
"refs/for/master".  I think most already do go through "refs/for/master" 
and the few times they do not, I would assume they have a good reason for 
it. 

Can you point out (or monitor for) cases where people go directly to 
"refs/heads/master" and it causes problems? 

Thanks, 




From:   Mickael Istria 
To: Cross project issues , 
Date:   01/07/2016 07:06 AM
Subject:[cross-project-issues-dev] Enforce Gerrit for Simrel?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi all,

Gerrit for SimRel has been widely used by many projects and the validation 
checks that come with Simrel have successfully caught a bunch of issues 
before the had the opportunity to break the Simultaneous Release. Gerrit 
and Code-Review can have an incredible effect on software quality, many 
projects and teams enforce it with success. I don't have metrics, but 
maybe David can say whether he felt a noticeable improvement in 
stability/quality since the inception of Gerrit a few months ago?

I believe it's the right time to start considering enforcing Gerrit usage 
for SimRel: a first implementation would be to have committers push to 
refs/for/master instead of master, and would either be reviewed by someone 
else, or review themselves their contribution. The Hudson validation job 
triggers automatically on any contribution and gives a vote if the 
contribution is breaking the build.

What do you think?
-- 
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] Neon M4 is now available

[David M Williams]

Not due to bug 484629, AFAIK, I think it was because it never got a "+1" 
from the package maintainer (Chuck Bridgham). 




From:   "Vaninder K Rajput" <vanin...@ca.ibm.com>
To: Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:   12/22/2015 10:19 AM
Subject:Re: [cross-project-issues-dev] Neon M4 is now available
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hello All, 

I couldn't find Eclipse IDE for JEE Developers in the list. Is that 
because of the bug (Bug 484629) ?




Thanks,

Vaninder Rajput 
Websphere Developer Tools
D3-231/8200 Warden/Toronto
email: vanin...@ca.ibm.com

IBM Canada | 8200 Warden Ave Markham ON | http://w3.canlab.ibm.com 

"David M Williams" ---12/18/2015 05:50:09 PM---Neon M4 has been added to 
the repository at http://download.eclipse.org/releases/neon/

From: "David M Williams" <david_willi...@us.ibm.com>
To: cross-project-issues-dev@eclipse.org
Date: 12/18/2015 05:50 PM
Subject: [cross-project-issues-dev] Neon M4 is now available
Sent by: cross-project-issues-dev-boun...@eclipse.org



Neon M4 has been added to the repository at 
http://download.eclipse.org/releases/neon/

That repo is a composite that now contains M4, M3, and M2. 

Most of the M4 EPP packages are available at 
https://www.eclipse.org/downloads/index-developer.php

A few packages had a problem with an error dialog at startup (See Bug 
484629). 
A work around was found and applied to those that had the problem, and an 
M4a version of those packages will be available early next week. 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Neon M4 staging repository is final (again)

[David M Williams]

It appears there were no other contributions after picking up these final 
ones. So 'staging' is now final, again, for M4. 
Markus and I will coordinate our "promoting" these tomorrow, on Friday, 
and via IM we have agreed 4 PM at the latest.
We hope earlier, if we can get the EPP packages produced, and the majority 
of them signed off sooner than that. 

Thanks all, 




From:   David M Williams/Raleigh/IBM@IBMUS
To: Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:   12/17/2015 07:04 AM
Subject:Re: [cross-project-issues-dev] Mac signing service issues 
-- updated plan for M4
Sent by:cross-project-issues-dev-boun...@eclipse.org



Given Mikael's  "new news", and other's requests, I have "re-enabled" the 
"VALIDATE" job on Hudson. 

It immediately started with these "changes"  listed:

Oomph (late)
Upgrade Buildship to 1.0.7 

Anyone else? 

I would like to set a deadline of 12 Noon today (Eastern time). I think it 
will be a bit rushed, but believe then we can still make M4 available on 
Friday, but, let's say we make the repo and EPP packages available by 4 PM 
on Friday, instead of 10 AM on Friday. I think that will give time for all 
the re-work, and sanity checks by EPP Package maintainers and at the same 
time "get it over with" before some start their end-of-year holidays. 

Let me know if any of these times are unreasonable or simply do not work 
due to timezone differences. (It is too early in the morning for me to 
compute or look them up myself :) ... not to mention, it depends on 
exactly who is effected and may need to "rebuild".) 

But, unless you hear otherwise, that is our revised plan. 

Thanks, 
 



From:Mikael Barbero <mik...@eclipse.org>
To:Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:12/17/2015 03:23 AM
Subject:Re: [cross-project-issues-dev] Mac signing service issues 
-- planfor M4
Sent by:cross-project-issues-dev-boun...@eclipse.org



The signing issue is due to too much difference between the system clock 
and the time stamping authority (and for some reason, NTP does not work 
the mac signing machine). I manually synched the time on the machine and 
the signing now works properly.

Cheers,
Mikael

Le 16 déc. 2015 à 22:03, David M Williams <david_willi...@us.ibm.com> a 
écrit :

Given there is currently "no solution in sight" for this week, I think the 
best course of action is to push ahead, and produce M4 as planned, with 
affected projects disabling "Mac signing". 

Once we have that build "in hand", a) if the user experience is "really 
bad", we can reconsider (but as far as know, if they are doing fresh 
install, then they have to do that "open" or "ctrl-open" trick we have 
used in the past -- that is, in the past there has been milestones without 
a Mac signature. b) if enough people are around next week, to redo 
contributions with Mac signed, we can do an M4a deliverable. 

But, in either case, since we are between a rock and a hard place, I think 
best to try and produce one as planned. Otherwise, we might be well into 
January before we could produce one, depending on everyone's holiday 
schedules. 

Thanks, 





From:Denis Roy <denis@eclipse.org>
To:Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:12/16/2015 01:36 PM
Subject:[cross-project-issues-dev] Mac signing service issues
Sent by:cross-project-issues-dev-boun...@eclipse.org



Folks,

The Mac signing service is currently broken. We're tracking the issue in :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=484438

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
[attachment "signature.asc" deleted by David M Williams/Raleigh/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/

Re: [cross-project-issues-dev] Mac signing service issues -- updated plan for M4

[David M Williams]

Given Mikael's  "new news", and other's requests, I have "re-enabled" the 
"VALIDATE" job on Hudson. 

It immediately started with these "changes"  listed:

Oomph (late)
Upgrade Buildship to 1.0.7 

Anyone else? 

I would like to set a deadline of 12 Noon today (Eastern time). I think it 
will be a bit rushed, but believe then we can still make M4 available on 
Friday, but, let's say we make the repo and EPP packages available by 4 PM 
on Friday, instead of 10 AM on Friday. I think that will give time for all 
the re-work, and sanity checks by EPP Package maintainers and at the same 
time "get it over with" before some start their end-of-year holidays. 

Let me know if any of these times are unreasonable or simply do not work 
due to timezone differences. (It is too early in the morning for me to 
compute or look them up myself :) ... not to mention, it depends on 
exactly who is effected and may need to "rebuild".) 

But, unless you hear otherwise, that is our revised plan. 

Thanks, 
 



From:   Mikael Barbero <mik...@eclipse.org>
To: Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:   12/17/2015 03:23 AM
Subject:Re: [cross-project-issues-dev] Mac signing service issues 
-- plan for M4
Sent by:cross-project-issues-dev-boun...@eclipse.org



The signing issue is due to too much difference between the system clock 
and the time stamping authority (and for some reason, NTP does not work 
the mac signing machine). I manually synched the time on the machine and 
the signing now works properly.

Cheers,
Mikael

Le 16 déc. 2015 à 22:03, David M Williams <david_willi...@us.ibm.com> a 
écrit :

Given there is currently "no solution in sight" for this week, I think the 
best course of action is to push ahead, and produce M4 as planned, with 
affected projects disabling "Mac signing". 

Once we have that build "in hand", a) if the user experience is "really 
bad", we can reconsider (but as far as know, if they are doing fresh 
install, then they have to do that "open" or "ctrl-open" trick we have 
used in the past -- that is, in the past there has been milestones without 
a Mac signature. b) if enough people are around next week, to redo 
contributions with Mac signed, we can do an M4a deliverable. 

But, in either case, since we are between a rock and a hard place, I think 
best to try and produce one as planned. Otherwise, we might be well into 
January before we could produce one, depending on everyone's holiday 
schedules. 

Thanks, 





From:Denis Roy <denis@eclipse.org>
To:Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:12/16/2015 01:36 PM
Subject:[cross-project-issues-dev] Mac signing service issues
Sent by:cross-project-issues-dev-boun...@eclipse.org



Folks,

The Mac signing service is currently broken. We're tracking the issue in :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=484438

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
[attachment "signature.asc" deleted by David M Williams/Raleigh/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] Mac signing service issues -- plan for M4

[David M Williams]

Given there is currently "no solution in sight" for this week, I think the 
best course of action is to push ahead, and produce M4 as planned, with 
affected projects disabling "Mac signing". 

Once we have that build "in hand", a) if the user experience is "really 
bad", we can reconsider (but as far as know, if they are doing fresh 
install, then they have to do that "open" or "ctrl-open" trick we have 
used in the past -- that is, in the past there has been milestones without 
a Mac signature. b) if enough people are around next week, to redo 
contributions with Mac signed, we can do an M4a deliverable. 

But, in either case, since we are between a rock and a hard place, I think 
best to try and produce one as planned. Otherwise, we might be well into 
January before we could produce one, depending on everyone's holiday 
schedules. 

Thanks, 





From:   Denis Roy 
To: Cross project issues , 
Date:   12/16/2015 01:36 PM
Subject:[cross-project-issues-dev] Mac signing service issues
Sent by:cross-project-issues-dev-boun...@eclipse.org



Folks,

The Mac signing service is currently broken. We're tracking the issue in :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=484438

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] "Aggregation model is inconsistent"errors

[David M Williams]

Ah, I'm glad this message finally came through ... it all depends on the 
"luck of the queue" or something. 

BUT, I have reinstalled, and even re-cloned, and still seeing the same 
problem with 'categories' in the b3 editor. Does anyone else? If I select 
the "validate" action it shows me there are several features in the 
Modeling Category that are "un-referenced" (or something like that). There 
is about 8 total. I'm not sure if features were attempted to be removed 
from the Modeling category? Or if some were being added? 

In any case, Modeling projects should be sure to take a look at "staging" 
repo, to make sure all is as intended. I think "everything is in" the 
repository, and this is just a category issue, since if I pick "validate 
aggregation" it passes OK. 

I have opened bug 484518[1] to track the difference in "results" between 
various forms of 'validate'. 

Thanks

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





From:   David M Williams/Raleigh/IBM@IBMUS
To: Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:   12/16/2015 05:52 PM
Subject:Re: [cross-project-issues-dev] "Aggregation model is 
inconsistent"   errors
Sent by:cross-project-issues-dev-boun...@eclipse.org



Michael, Yes, I agree that "if you are going to fail a build, a Gerrit 
build it the best kind to fail" ... but, still, I wouldn't exactly call it 
a "good thing" when someone makes an all too common of an error. 
But, I indeed would not have to "revert" anything in that case, and that 
*is* a good thing. :) 

As for the "categories". I was basing my statement on my "local run" in 
the b3 aggegator editor and I think I must have something wrong with my 
install, so I will try to fix that up today to avoid future false alarms. 

Thanks, 



From:Mickael Istria <mist...@redhat.com>
To:cross-project-issues-dev@eclipse.org, 
Date:12/16/2015 04:02 AM
Subject:Re: [cross-project-issues-dev] "Aggregation model is 
inconsistent" errors
Sent by:cross-project-issues-dev-boun...@eclipse.org



On 12/16/2015 09:39 AM, David M Williams wrote:
As of right now, the 'head' of the model is breaking due to invalid 
"categories" and the "Gerrit job" is breaking due to invalid "contacts". 
@David:
As far as I can see, the failing Gerrit job is a good thing, since it did 
vote -1 on an ongoing review, and it helped the other to fix their 
contribution before they could merge it.
Where is the CI job highlighting that HEAD is breaking? I'm on 
https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.BUILD__CLEAN/
and everything is green.

@All:
Like many are already doing, even if you're a SimRel committer and if 
you're using the simrel model editor, it's always a good idea to take 
advantage of the validation step offered by Gerrit: 
https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Contribute_via_a_Gerrit_review
. When pushing to Gerrit, the model is automatically validated and you get 
a -1 when the model is broken (because of your change, or an earlier one 
on your branch but that 2nd case isn't frequent), then you can amend your 
patch and submit it again until you get a +1 and permission to merge via 
Gerrit if everything seems good. This workflow prevents from breaking 
"production" branches.
-- 
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


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] "Aggregation model is inconsistent" errors

[David M Williams]

Michael, Yes, I agree that "if you are going to fail a build, a Gerrit 
build it the best kind to fail" ... but, still, I wouldn't exactly call it 
a "good thing" when someone makes an all too common of an error. 
But, I indeed would not have to "revert" anything in that case, and that 
*is* a good thing. :) 

As for the "categories". I was basing my statement on my "local run" in 
the b3 aggegator editor and I think I must have something wrong with my 
install, so I will try to fix that up today to avoid future false alarms. 

Thanks, 



From:   Mickael Istria <mist...@redhat.com>
To: cross-project-issues-dev@eclipse.org, 
Date:   12/16/2015 04:02 AM
Subject:Re: [cross-project-issues-dev] "Aggregation model is 
inconsistent" errors
Sent by:cross-project-issues-dev-boun...@eclipse.org



On 12/16/2015 09:39 AM, David M Williams wrote:
As of right now, the 'head' of the model is breaking due to invalid 
"categories" and the "Gerrit job" is breaking due to invalid "contacts". 
@David:
As far as I can see, the failing Gerrit job is a good thing, since it did 
vote -1 on an ongoing review, and it helped the other to fix their 
contribution before they could merge it.
Where is the CI job highlighting that HEAD is breaking? I'm on 
https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.BUILD__CLEAN/ 
and everything is green.

@All:
Like many are already doing, even if you're a SimRel committer and if 
you're using the simrel model editor, it's always a good idea to take 
advantage of the validation step offered by Gerrit: 
https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Contribute_via_a_Gerrit_review
 
. When pushing to Gerrit, the model is automatically validated and you get 
a -1 when the model is broken (because of your change, or an earlier one 
on your branch but that 2nd case isn't frequent), then you can amend your 
patch and submit it again until you get a +1 and permission to merge via 
Gerrit if everything seems good. This workflow prevents from breaking 
"production" branches.
-- 
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

[cross-project-issues-dev] Declaring Neon M4 repository done

[David M Williams]

It is not quite, literally "done", since the last "CLEAN" job is still 
running, with Eike's attempt to fix-up the modeling features. 
While that may take a few hours to finish, I have a appointment "first 
thing" in the morning, so must go to bed early. 

But, I have disabled "validate jobs" which is where the work flow starts. 

FYI, I am not completely opposed to "re-building", on Thursday,  if some 
of the technical infrastructure problems are fixed early Thursday ... 
But I did not want to wait until Monday when some *might* be fixed, since 
as I understand it, some people will be on holiday by then -- when it 
rains, it pours. 

So, we'll do the best we can with what we have, and THEN decide if we need 
to postpone the whole thing, do to these various issues. I think (by 
intuition) we will be fine, for an M4 deliverable, and then can 
hit the ground running for M5? 

Also, to give you warning, I have not looked closely at the input, to see 
if everyone who has "declared by M4" is actually *in* M4. Sorry I've not 
had time to police that and so far do not have an automated way to tell. 

Thanks for everyone's help and patience. 





From:   Eike Stepper <step...@esc-net.de>
To: cross-project-issues-dev@eclipse.org, 
Date:   12/17/2015 12:49 AM
Subject:Re: [cross-project-issues-dev] "Aggregation model is 
inconsistent"errors
Sent by:cross-project-issues-dev-boun...@eclipse.org



Am 17.12.2015 um 00:31 schrieb David M Williams:
> Ah, I'm glad this message finally came through ... it all depends on the 
"luck of the queue" or something.
>
> BUT, I have reinstalled, and even re-cloned, and still seeing the same 
problem with 'categories' in the b3 editor. 
> Does anyone else? If I select the "validate" action it shows me there 
are several features in the Modeling Category 
> that are "un-referenced" (or something like that). There is about 8 
total. I'm not sure if features were attempted to 
> be removed from the Modeling category? Or if some were being added?
>
> In any case, Modeling projects should be sure to take a look at 
"staging" repo, to make sure all is as intended. I 
> think "everything is in" the repository, and this is just a category 
issue, since if I pick "validate aggregation" it 
> passes OK.
It seems that all the problems have been introduced by different commits 
of Anthony Hunter (cc'ed in a separate mail) 1 
or 2 days ago. Validate detects the following errors, for which I've added 
the respective commits:



 commit 4ded350dbeea781ffc6a87c18c9c0d3294b25c1e (one feature removed)
 Committer: Anthony Hunter <antho...@ca.ibm.com> 2015-12-16 01:59:09


 
(DUP)

 
(DUP)


 commit 7dc9d997c30c1b86e59f202380626f40db765556 (two features 
removed)
 Committer: Anthony Hunter <antho...@ca.ibm.com> 2015-12-15 23:15:16





 commit 94758639874aa4e29a5577d70f77bb44cf7356a5 (two features 
removed)
 Committer: Anthony Hunter <antho...@ca.ibm.com> 2015-12-15 20:16:48





 commit c1d3ff108bf56f49214efdad95c5a0c50049d62c (two features 
removed)
 Committer: Anthony Hunter <antho...@ca.ibm.com> 2015-12-15 20:16:23

I hope that helps to fix it.

Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



>
> I have opened bug 484518[1] to track the difference in "results" between 
various forms of 'validate'.
>
> Thanks
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=484518
>
>
>
>
>
> From: David M Williams/Raleigh/IBM@IBMUS
> To: Cross project issues <cross-project-issues-dev@eclipse.org>,
> Date: 12/16/2015 05:52 PM
> Subject: Re: [cross-project-issues-dev] "Aggregation model is 
inconsistent"errors
> Sent by: cross-project-issues-dev-boun...@eclipse.org
> 

>
>
>
> Michael, Yes, I agree that "if you are going to fail a build, a Gerrit 
build it the best kind to fail" ... but, still, 
> I wouldn't exactly call it a "good thing" when someone makes an all too 
common of an error.
> But, I indeed would not have to "revert" anything in that case, and that 
*is* a good thing. :)
>
> As for the "categories". I was basing my statement on my "local run" in 
the b3 aggegator editor and I think I must 
> have something wrong with my install, so I will try to fix that up today 
to avoid future false alarms.
>
> Thanks,
>
>
>
> From: Mickael Istria <mist...@redhat.com>
> To: cross-project-issues-dev@eclipse.org,
> Date: 12/16/2015 04:02 AM
> Subject: Re: [cross-project-issues-dev] "Aggregation model

[cross-project-issues-dev] "Aggregation model is inconsistent" errors

[David M Williams]

If I've said it N times, I've said it N+1 times, if you change 
"categories" or change "contacts" you need to use the b3 aggegator editor, 
and make the changes using the "model editor". The reason is these changes 
make changes in two files, the "main" one, "simrel.b3aggr", and your 
individual ".b3aggrcon" file -- and then both files need to be 
committed/pushed. 

As of right now, the 'head' of the model is breaking due to invalid 
"categories" and the "Gerrit job" is breaking due to invalid "contacts". 

I have not looked, yet, for "who did what", but thought I'd send this 
blanket reminder, and perhaps by the time I wake up, it will be all fixed. 
:) 

If not, I will "slash and burn" to make the model valid, and/or completely 
revert changes that broke the model, if I can tell. That is, I will not be 
able to "fix correctly" since I do not know what was intended. 

If anyone needs specific help, please open a cross-project bug asking for 
it and stating what you intend to accomplish. Thanks. 

Hope this reminder helps, 


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Nighty snapshots for simrel and EPPMars.2

[David M Williams]

Probably better asked on epp-dev list, but I'll tell you what I know. 

To get a "nightly" EPP repo, you would have to use "last successful" repo 
on Hudson, which has a URL of 
https://hudson.eclipse.org/packaging/job/mars.epp-tycho-build/lastSuccessfulBuild/artifact/org.eclipse.epp.packages/archive/repository/

I always forget, and have to start at the EPP home page [1] to get the 
right links, which still take some "drilling down" to find the repository, 
instead of the packages. And, for Neon, you'd just have to "type over" the 
'mars' part of URL and use 'neon' instead. 

BUT THEN, you would have to be sure what you wanted was actually in there. 
I have not, for example, updated the Eclipse and Equinox contribution past 
our Mars.1 release. 
That is, until just now. :) So should get an 'update' in a few hours for 
you to try out. And this was using our Platform build from M20151209-1000. 
I would never contribute a "nightly" to EPP (we do not even have 
"nightlies" of our Mars.2 stream), and I do not believe EPP has any 
concept of a true "nightly". It is simply rebuilt whenever anyone makes a 
new contribution. 

As always, caution is urged and these builds would not be for anyone using 
them "for production".  But, otherwise, it's great to get the early 
testing. 

Hope this helps, 

[1] https://www.eclipse.org/epp/





From:   Mickael Istria 
To: Cross project issues , 
Date:   12/14/2015 10:34 AM
Subject:[cross-project-issues-dev] Nighly snapshots for simrel and 
EPP Mars.2
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi all,

Some users have been asking how to get into their IDE the patches for SWT 
on GTK. Although those patch are available and merged, it remains quite 
tricky for users of Mars.1 to retrieve them. Indeed, the only 2 
alternatives I'm aware of are:
1. create a new install of Eclipse SDK from Platform 4.5 nightly build 
(and re-install everything they need)
2. Install the Platform feature from the 4.5 nightly build (which will 
most likely trigger remediation because of the version change in SWT 
bundle)
None of those 2 is very smooth.

So, for those users, the best thing would be to be able to point them to a 
nightly build of Mars.2 and EPP packages, containing the latest build of 
Eclipse 4.5.2. Then users could add this site to their available software 
sites, and try a "Check for updates"/
Is such a site available? Would it be possible to create it?

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

[cross-project-issues-dev] Final Simultaneous Release Plan and Requirements for Neon

[David M Williams]

As always, we, the Planning Council (PC), commit to finalizing the Neon 
Plan and Requirements by M4. And we have now done that. Nothing is too 
different but  there are some differences. So read carefully and keep this 
note for reference. 

- The Plan [1]: milestones are similar to previous years, but after the 
release in June, we will plan on having 3 "update releases" instead of 2, 
as we have done in previous years. (The Mars plan remains the same: one 
more update release in February.)  Besides "increased frequency" we also 
had the goal of having the update releases more evenly spaced throughout 
the development year, basically "one per quarter". It turns out to be 
easiest, we believe, to tie the update releases to the same day as three 
of the "Neon+1" milestones [2]. More specifically, that is Milestones 2, 4 
and 6 in September, December, and March. See the Plan Section "Update 
Releases" [3] for more detail. (And, please, read the whole plan [1], 
especially if new to the Simultaneous Release.) 

We recognize this will be "more work" for most projects, but keep in mind 
exactly how much work is done for each update release is still up to each 
project. Some may barely do "minor service", some may have "new features". 
It is up to the project. But you can not have "breaking changes", except 
in rare circumstances. 

One implication of this change is that the last Update Release will come 
after EclipseCon NA, in 2017, assuming EclipseCon is scheduled similar to 
how it is currently. 

While not relevant for a while, there are other changes for dates related 
to the Update Releases: There will no longer be a "warm-up RC1" that is 
done two weeks early. Instead, we will just start off with a "real RC1" 
only one week before RC2. This is because we, the PC, feel projects have 
matured enough at this process to no longer need a warm-up RC, not to 
mention we have a compressed schedule. Similarly, while less important for 
Neon than for Neon+1, in the future we will no longer have a "two week 
window" for the first three milestones. We will instead have a one week 
window all the time. Again, this is due to the maturity of Eclipse 
projects, plus our desire to have more uniformity in the schedules. This 
does not effect Neon, since we are already moving to the 1 week window as 
of right now! for M4. (Everyone "in" by Wednesday, right?) 

- The requirements [4]: They are the same, except for two additions. You 
can find them in the release document by searching for "[added 12/2015, 
for Neon]". But I will paste them below, for a quick read. I think the 
reasons for them are fairly obvious, if you've followed the many 
discussions we've had on this list and in bugs for years, but if any one 
has any questions, I'll address in a separate note, instead of making this 
note more wordy. And, again, please read whole document, even if 
experienced. 

= = = = 
[added 12/2015, for Neon] While part of the mechanics of contributing to 
the build, it is required that any contribution to the Simultaneous 
Release repository be done by a unique change to the b3aggrcon file. There 
are two ways to do this. First, your contribution repository can point to 
a simple repository where you know for sure there is only one version of 
your contribution available. Second, your contribution repository can be a 
composite repository but then you name exactly which versions to include. 
That is you need to specify all 4 version fields. You can, of course, do 
both methods, simple repository and name exact versions if you want the 
safety of that redundancy. 

[added 12/2015, for Neon]. Note: If a jar is already signed by the Eclipse 
certificate, then it must not be re-signed by projects for the release 
train. 
= = = = 

As always, questions are welcome. In the mean time ... back to getting M4 
done! 

Thank you all for participating and contributing to Eclipse. 



[1] https://wiki.eclipse.org/Neon/Simultaneous_Release_Plan
[2] feel free to suggest a name for Neon+1, in Bug 483685
[3] 
https://wiki.eclipse.org/Neon/Simultaneous_Release_Plan#Update_Releases 
[4] https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] repo.eclipse.org server unavailable

[David M Williams]

I see this too. Did not see a bug open for it, so opened the following one 
as a blocker: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=483727




From:   Andrey Loskutov 
To: cross-project-issues-dev@eclipse.org, egit-...@eclipse.org, 
webmas...@eclipse.org, 
Date:   12/05/2015 06:51 AM
Subject:[cross-project-issues-dev] repo.eclipse.org server 
unavailable
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi,

egit build job currently reports errors like:

Downloading: 
https://repo.eclipse.org/content/repositories/egit-snapshots/org/eclipse/egit/egit-parent/4.2.0-SNAPSHOT/maven-metadata.xml

[WARNING] Could not transfer metadata 
org.eclipse.egit:egit-parent:4.2.0-SNAPSHOT/maven-metadata.xml from/to 
repo.eclipse.org 
(https://repo.eclipse.org/content/repositories/egit-snapshots/): Failed 
to transfer file: 
https://repo.eclipse.org/content/repositories/egit-snapshots/org/eclipse/egit/egit-parent/4.2.0-SNAPSHOT/maven-metadata.xml
. 
Return code is: 503 , ReasonPhrase:Service Temporarily Unavailable.

See https://hudson.eclipse.org/egit/job/egit/4044/console

By opening 
https://repo.eclipse.org/content/repositories/egit-snapshots/org/eclipse/egit/egit-parent/4.2.0-SNAPSHOT/maven-metadata.xml
 

in browser, I see this:

Service Temporarily Unavailable

Apache/2.2.12 (Linux/SUSE) Server at repo.eclipse.org Port 443

Is this known / addressed?

Thanks,
Andrey

-- 
Kind regards,
Andrey Loskutov

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




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

[cross-project-issues-dev] Reminder that M4 is coming up ... with a "one-week window"

[David M Williams]

I am sure nearly everyone is aware of our Neon schedule, but for the few 
of you who might not be, I wanted to remind everyone that this is the 
milestone we move to a "one-week window". 

That is, the platform will deliver their contribution on Friday 12/11, and 
the latest everyone else is due is 12/16. For this reason, I encourage 
everyone to be sure to a) make warm-up builds available for your 
consumers, and b) for others to build on those warm-up builds, so you can 
iron out any problems before the very last few days. It is much less 
stressful. :) 

Thank you all! 




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Neon M3 is available

[David M Williams]

No bad luck today! 

We have "turned on" the Neon M3 repositories for 'update' from previous 
Neon installations. 
(As a reminder, .../releases/neon is a composite consisting of M3, M2, and 
M1. Please open a bug if anyone observes any problems with that ... as 
sometimes happens if features are removed, and similar). 

Plus, many of the EPP packages are available on the developer's download 
tab, namely
https://www.eclipse.org/downloads/index-developer.php
More of them will be available soon, as package maintainers give their 
"OK" on epp-dev list. (hint, hint :) 


Much thanks to everyone who contributed to this milestone! 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Status and outlook for Neon M3

[David M Williams]

I can not believe it, but it looks like you all have done it again. A 
teeny tiny bit late (I hope to be a sleep when it is done :) but, "done in 
time" for M3. 

The "final build" is still testing itself at this moment, but should 
promote itself to .../releases/staging in an hour or so. Which I think 
will give time for sanity checks and EPP to finish building the packages 
in time for their smoke tests on Thursday, and assuming all goes well will 
still promote M3 on Friday. 

For the curious, I've documented "the final hours" in bug 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=481095 and will quote last 
comment here, since it effects 3 to 5 projects. 

- - - - - - - - - - - - - - 

I have submitted [Brian's] DTP b3aggrcon file. 

Plus, I have re-enabled org.eclipse.emf.oda.sdk feature, since the 
constraints now aggregate, with the new [reverted] DTP versioning. 

= = = = =

I thought we needed WTP to react since they had to make change for DTP 
2.0, but they must have used extra wide ranges since they still aggregate 
ok.

= = = = = 

All the initial validation passes, the only place things might go wrong is 
if a pack.gz file won't unpack and verify. We should know in a few hours. 

= = = = = 

Off topic: I found a way to re-enable MAT, even tough BIRT is still 
disabled, by simply disabling the FEATURES of the BIRT repository, not the 
whole repository. This leaves BIRT's repo open for others to pull from. 
Apparently, MAT may depend on some bundles in that repo, but not on 
anything that requires runtime.compatibility. 

That leaves BIRT and ObjectTeam the only disabled projects for M3. 
OjectTeam has explained [here] on cross-project list. Have not heard from 
BIRT, other than that they plan to participate in Neon.

- - - - - - - - - - - - - - 

Thanks to all for getting M3 in shape, on time. 
Now for the most important part ... test well! 

Thanks again, 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Announcing JDK 9 support for EclipseNeon

[David M Williams]

I guess my question, after reading "proprietary" (non-spec'd, available 
only through APIs) is how that works with projects like "OpenJDK"? (vs. 
Oracle, and others).
Is it that kind of "proprietary"? That they will have to come up with 
their own "format" that works with the APIs? 

I am just curious, but, seems kind of like a time waster, if I am 
interpreting the word correctly. 
I guess it could be a "point of competition", for better or for worse, on 
who has the most efficient format? 





From:   "Stephan Herrmann" 
To: "Cross project issues" , 
cross-project-issues-dev@eclipse.org, 
Date:   10/28/2015 12:48 PM
Subject:Re: [cross-project-issues-dev] Announcing JDK 9 support 
for Eclipse Neon
Sent by:cross-project-issues-dev-boun...@eclipse.org



Tom,

I don't see a conflict between Jay's and your observations:

Yes, users will be able to create / compile / package modules.
No, users will not create Jimage files.

Whether or not it is a module is a conceptual question. It needs
a module-info.java / module-info.class and there you are.

The Jimage format, by contrast is a purely technical question
of how bits and pieces are encoded / packaged.
JDK uses Jimage to ship their libraries, user modules are
shipped as jars.

So when you convert a "legacy" user library into a module,
technically that would be a jar -> jar transformation.

Makes sense?
Stephan


- ursprüngliche Nachricht -

Subject: Re: [cross-project-issues-dev] Announcing JDK 9 support for 
Eclipse Neon
Date: Mi 28 Okt 2015 04:30:11 CET
From: Tom Schindl
To: cross-project-issues-dev@eclipse.org

>From the j1 session(s) - I attended I can not share this! They've been
talking about making modules out of libraries jars.

Jars on the classpath get automatically wrapped into 1 virtual module at
runtime. My understanding was that all you need to to do is to call a
command line app to make a module from a jar (which although
autogenerates the module-info.java).

There are chances although that I completely screwed this up. There's
been a ton of informations on all this stuff and without at least having
had a hands on it's really easy to mix things up.

Tom

On 27.10.15 19:35, Jayaprakash Arthanareeswaran wrote:
> My understanding (from JEP 220) is that these run-time images are
> created specifically for the JDK/JRE and the IDE is only expected to
> read these.
> User defined modules will either be in source form or JAR form. One of
> the goals of the JEP 220 is this:
> 
> "Restructure the JDK and JRE run-time images to draw a clear distinction
> between files that developers, deployers, and end-users can rely upon
> and, when appropriate, modify, in contrast to files that are internal to
> the implementation and subject to change without notice. "
> 
> The way I see it, a Jimage is purely meant to be part of a JDK and
> nowhere else.
> 
> Regards,
> Jay
> 
> Inactive hide details for Mike Milinkovich ---10/28/2015 02:49:43
> AM---On 27/10/2015 5:18 PM, Daniel Megert wrote: > > "InsteadMike
> Milinkovich ---10/28/2015 02:49:43 AM---On 27/10/2015 5:18 PM, Daniel
> Megert wrote: > > "Instead, API is provided for reading the content of
> 
> From: Mike Milinkovich 
> To: Daniel Megert , Cross project issues
> 
> Date: 10/28/2015 02:49 AM
> Subject: Re: [cross-project-issues-dev] Announcing JDK 9 support for
> Eclipse Neon
> Sent by: cross-project-issues-dev-boun...@eclipse.org
> 
> 
> 
> 
> 
> On 27/10/2015 5:18 PM, Daniel Megert wrote:
> 
> > "Instead, API is provided for reading the content of such image." 
> 
> ==> The format is not specified but APIs allow to read the content.
> 
> 
> Maybe I am wrong, but since we are a Java IDE don't we also have to
> *write* the content of such files?
> 
> -- 
> Mike Milinkovich_
> __mike.milinkovich@eclipse.org_ 
> +1.613.220.3223 (mobile)
> _
> _EclipseCon Europe 2015
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> 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
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Re: [cross-project-issues-dev] DTP major version bump for Neon

[David M Williams]

I would like to comment on this issue as well. 

If there are no breaking API changes, the major version should not 
increase. Typically increasing the BREE level is seen as "adding API" 
(from what ever is new in the JRE that the BREE is increased to) but not 
breaking API. And, adding API is recommended to be a 'minor' increase in 
version. Where Brian recommended "1.12 to 1.12.1" I would recommend 1.12 
to 1.13, based on the guidelines. 

Konstantin, I think the place where your interpretation is too strict is 
where you say 

Here is my decision process… Can you take an Eclipse installation with the 
previous version of your project where all dependencies only use your 
public API, update it to the new version and have the installation 
continue to function. The answer in the case of a BREE bump, is “maybe”, 
so the major version bump is required.


There is no "maybe" in this case. Even though the BREE said 1.5, I can 
assure you anyone running DTP Tools for the past several years has not 
been using 1.5. Even if they had been, or, imagine instead the question 
was if the issue was "1.7" to "1.8". Requiring a higher level JRE to run 
is not consider "breaking". As you yourself admit, that's been done 
repeatedly as new versions of Java come out. 

Hence, I recommend you 'revert' the changes you made for the major version 
bump. This is a hard request for me make, so I don't make it lightly, 
because I know you stepped in to build DTP, before anyone else did. And 
that is much appreciated, by me and many others. But ... the change in 
major version will break many adapters needlessly, since no API is 
breaking. And, such breakage will cause Eclipse to be viewed less 
favorable by many adopters, perhaps even cause some smaller adopters to 
not "move up" -- which is already a problem that Eclipse as a whole has 
not dealt with well. And, we can be assured no users will be effected, 
since we all assume they will be running 1.8 anyway. (Even that change to 
1.8 is questionable. Especially if headless versions of DTP Tools are used 
"server side", but, I do not know that to be the case, so I won't argue 
about that case. But, changing the BREE when it is not required by the 
bundle's source code is definitely more aggressive than the guidelines [1] 
given in the Simultaneous Release requirements [2]). 

So ... please! :) 

As a wordy aside, I heard 10 years ago, from some leaders that started 
Eclipse (that are no longer around) that "projects with one or two 
committers, are the ones most likely to break API [or adopters]". While 
not strictly applicable to this case, since you are not breaking API, I 
think the message is when there are only one or two committers on a 
project, they should be extra careful (that is, allow LOTS of time for 
review) before they make a change that would break adopters. I think this 
is especially relevant to DTP precisely because it "has not changed" in 
several releases, so adopters would be especially hard-hit by such a 
change and this, in turn, have an indirect negative impact on users. 

I've said enough, except to thank you again, for stepping in to build DTP 
quickly, when it was broken by the Platform removing the "runtime 
compatibility" bundle. I certainly do not fault you for trying to make 
things simpler for yourself, but in this case, simpler for you means a lot 
more complicated for many others. 

Thanks, 

[1] https://wiki.eclipse.org/Execution_Environments 
[2] 
https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Execution_Environment_.28tested.29


 



From:   Konstantin Komissarchik 
To: Brian Payton/Santa Teresa/IBM@IBMUS, Cross project issues 
, 
Date:   10/27/2015 07:48 PM
Subject:Re: [cross-project-issues-dev] DTP major version bump for 
Neon
Sent by:cross-project-issues-dev-boun...@eclipse.org



Brian,
 
The version changes have already gone in and we are already contributing 
DTP v2 to Neon aggregation. Making all the necessary updates took a 
non-trivial amount of my time.
 
I posted the version question on dtp-dev on 10/13, but no one responded, 
so I proceeded with the path that makes the most sense to me as the sole 
active DTP committer.
 
https://dev.eclipse.org/mhonarc/lists/dtp-dev/msg02320.html
 
Maintaining backwards compatibility as we undertake some sorely-needed 
improvements would use up contributor cycles that DTP does not have to 
spare. The simultaneous release process purposefully allows projects to 
ship API-breaking major releases once a year and many projects have gone 
this route.
 
Thanks,
 
- Konstantin
 
 

From: Brian Payton
Sent: Tuesday, October 27, 2015 3:19 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
 
 
Sorry, I was away for a few days on vacation and missed this exchange.

I agree with Ed and others that moving the BREE to Java 8 does not imply 
that we 

[cross-project-issues-dev] Did I mess up our procedure for Neon? With respect to declaring, and enablement, and our "list of participants"?

[David M Williams]

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

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

[David M Williams]

Maybe it is obvious, but I have a feeling that Wayne would wish I would 
have reminded everyone to create a release record, to go along with your 
announcements. :) 

I am lucky and never have ... but appears the "how to" instructions have 
moved to 

https://www.eclipse.org/projects/handbook/#pmi-releases

Thanks, 





From:   Thomas Watson/Austin/IBM@IBMUS
To: "Cross project issues" , 
Date:   10/21/2015 11:29 AM
Subject:[cross-project-issues-dev] Equinox participation in Neon
Sent by:cross-project-issues-dev-boun...@eclipse.org



Equinox will be participating in the Neon Simultaneous release with an 
offset 0.

The planned release is 4.6.0.

Tom

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


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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"?

[David M Williams]

Thanks for letting us know, Gunnar. I'll remove your b3aggrcon file from 
master. 

You'll still need to do a release record. :) 





From:   Gunnar Wagenknecht <gun...@wagenknecht.org>
To: Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:   10/21/2015 01:02 PM
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"?
Sent by:cross-project-issues-dev-boun...@eclipse.org



David,

That brings up a good question ... The Gyrex project will continue to 
participate in the release train, but we'll no longer contribute to the 
release train repo.

-Gunnar


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






> Am 21.10.2015 um 07:01 schrieb David M Williams 
<david_willi...@us.ibm.com>:
> 
> 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




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Next turn of the crank ... runtime compatibility bundle

[David M Williams]

Since no response from Birt, I have disabled BIRT from the aggregation, 
for now (which required me to also disable MAT chart feature, for now, 
since depends on BIRT)  so that we can see who else might still depend on 
compatibility bundle. 

According to my local builds, I think PTP does? 

If so, please correct soon, please ... I'd like to know if there's any 
more, after that is fixed? 

Thanks! 




From:   David M Williams/Raleigh/IBM@IBMUS
To: Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:   10/20/2015 03:02 PM
Subject:Re: [cross-project-issues-dev] ... runtime compatibility 
bundle ... and LDT ... and Neon M3
Sent by:cross-project-issues-dev-boun...@eclipse.org



OK, ready to try again? Since the LDT contribution has not changed, I have 
disabled it from the aggregation build, so that we can see who else still 
refers to the defunct compatibility runtime bundle.

According to my local builds, BIRT will be the next project to fail ... 
now that DTP has been fixed (thanks Konstantin, and others). 
[Correction

Please correct any failures as soon as possible. That is, don't wait until 
your +N day. You can always contribute your final content later, but build 
"breaks" should be corrected right away. 

Same goes for you, LDT team, though I know your "break" isn't obvious, and 
realize you have some "redesign" work to do to figure out how to deliver 
"just your code" (and not all dependencies too). 

Thanks all, 





From:David M Williams/Raleigh/IBM@IBMUS
To:Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:09/30/2015 11:04 AM
Subject:Re: [cross-project-issues-dev] DTP for Neon stream ... 
runtime.compatibility ... and LDT? ... and Neon M2
Sent by:cross-project-issues-dev-boun...@eclipse.org



OK, I give up. 

It appears some projects are not going to be able to react to the removal 
of runtime.compatibility bundle, for M2, so I have re-enabled the LDT 
contribution. (Bug 478009 and Bug 478330).
This will allow the aggregation build, at least, to complete, so that 
others can make progress. 

This won't help projects who have a direct dependancy on, say, DTP (which 
in turn as a dependency on runtime compatibility bundle) since they depend 
on it, but do not provide it. 
For those people, the only work around I know of is to "include" only that 
bundle from our M1 repository, or something similar. 
Less that ideal, but I'd like to push forward and see if we can get out 
some form of M2 that can be used to create a cleaner M3! 

Let me know if suggestions or alternative approaches. (And, FYI, it does 
not appear that extending the deadline a few days will help with the 
runtime compatibility issue, but, if anyone has been blocked due to this 
issue, and needs a few days to work around the problem, I think it 
reasonable to consider an extension of a few days ... if you make such a 
request, please be specific ... I'd hate to extend it to Monday instead of 
Friday (let's say) and then that still not be enough time.) 

Thanks, 




From:David M Williams/Raleigh/IBM@IBMUS
To:Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:09/28/2015 08:47 PM
Subject:Re: [cross-project-issues-dev] DTP for Neon stream ... 
runtime.compatibility ... and LDT? ... and Neon M2
Sent by:cross-project-issues-dev-boun...@eclipse.org



I hope everyone remembers that Neon M2 is this Friday ... and that means 
your Neon M2 contributions must be done by Wednesday. 

AND .. it seems, some have not yet reacted to the platform removing 
org.eclipse. runtime.compatibility bundle (Bug 394739). 

AND .. some have been "getting it automatically" from the current Sim. 
Release contributions, because Lua Development Tools (LDT) duplicates it 
(and many others) in their repository (Bug 478009). 

Since LDT has not updated their repo yet for Neon, I fear some may have of 
a false sense that "everything is ok".

Put more bluntly, we all know, some projects do not build against the 
latest version of their pre-reqs! And, we all know that some projects 
won't react until "the build fails". 

Therefore ... I am about to make the build fail for others, by removing 
LDT's massive contribution. 

If someone has a better suggestion, that would be good to hear, but I hope 
I am doing everyone a favor, by making the problem more apparent in the 
aggregation build. 

(And, greatest thanks to those of you who HAVE reacted to this change 
already ... thanks to all your release engineers!) 

Thank to you all, 






From:David M Williams/Raleigh/IBM@IBMUS
To:Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:09/21/2015 08:09 PM
Subject:Re: [cross-project-issues-dev] DTP for Neon stream ... and 
LDT?
Sent by:cross-project-issues-dev-boun...@e

[cross-project-issues-dev] Belated heads-up, if you use Tycho, and the tycho-eclipserun-plugin and want to move to M2

[David M Williams]

As part of Tycho's eclipserun plugin, you need to specify a repository for 
Tycho (and p2) to fetch components from. Tycho starts off with a minimal 
set, and then you can add more IUs for constructing a minimal "eclipse 
runtime" that is needed for your task. 

In M2, we introduced a bug that causes some "minimal sets" of bundles to 
not run.

We in our platform builds discovered this problem, (bug 478984 [1]) and 
now I have heard of another project that has hit the same problem (WTP, in 
bug 479805 [2] ) so I thought best to warn others. 

The easiest fix is to use, instead of M2, the first I build with the fix, 
I20151006-0800. I recommend that one, simply because it is closest to M2 
and it has been used successfully for this task. You never can tell, 
subsequent I-builds might have other bugs. :/ 

I could not reproduce the problem with a minimal pom, and a minimal 
eclipserun task (using antRunner with a "Hello World" ant task) so it 
might not always occur, but we've seen it with producing JavaDoc, and for 
the generation API descriptions. 

The issue might very well manifest itself in other situations (other than 
building) where a "minimal set" of components are crafted. 

Thanks for reading and apologies for the bug and this late notification of 
it. 

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=478984
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=479805




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] What has the Planning Council done now?

[David M Williams]

Not near as much as the title implies, but thought that title would catch 
your attention. :) This is primarily a "keeping everyone informed" note. 

We did, at our last meeting, officially agree on the Milestone dates, RC 
dates, and release date for Neon. 

If you do not recall, all we had currently agreed to only the first four 
milestones, for this calendar year. Once we made some high-level decisions 
about the Neon (and remaining Mars) update releases, it was clear the 
remaining milestone dates for Neon should have a similar pattern as 
previous years.  That is what we have put in our plan [1]. 

For the table version, see the Neon Plan schedule [2]. I will be updating 
the calendar [3] later this week. 

A bit off topic, but if anyone uses RSS (XML feeds) for the Google 
Calendar, you have to change soon, by mid-November. I received a notice of 
this since I own some calendars there. If you did not get a notice, and if 
you would like to read about it and alternatives to use instead, see their 
support note [4] or, you could just google for it. :) 

= = = = = = = = = = = = = = = = = = = = = = = = = = = = 

In case you have not heard this before, we are considering three Neon 
update releases, instead of two?

While we have not made a firm decision, nor exact dates, we have 
tentatively planned for three update releases for Neon, rather than the 
traditional two that we have done since forever. They would be 
approximately equally spaced, one per quarter, at around the same time as 
Neon-Plus-One milestones 2, 4, and 6, in other words, around September, 
December, and March. We will have final decisions and dates by 
mid-November.

I thought I'd give this "early warning" in case this change concerns or 
effects anyone in ways we do not know. If so, then you would still have 
time to talk to your Planning Council representative before our next 
meeting, November 11. You could ask them "why haven't you told us about 
this yet?" :)  More seriously, please let them know your concerns, or what 
you want to get out of it. We are making this change since there have been 
some general requests to allow more frequent opportunities for people to 
provide new features or bug fix releases to their users.  It does imply 
some amount of extra work for each project on the release train, but, we 
think not too much -- depending on what the project wants to release. 

To continue being serious, if you do have any questions, concerns, or 
compliments, please discuss with your PMC, Strategic member company, or 
directly to your Planning Council representative. I am just giving notice 
here, not asking for a large group discussion. 

= = = = = = = = = = = = = = = = = = = = = = = = = = = =

Perhaps not as interesting at the above, we also decided to codify 
officially in our plan, the principle we followed at the end of Mars.1: 

A rebuild during the quiet, final week before a release implies an 
automatic slip of one week for the official, simultaneous release date. 

I just wanted to point that out, so everyone would know about that 
constraint in the future, no one would be surprised, and we would all have 
the same expectations during that final week. In other words, just keeping 
you informed. 

= = = = = = = = = = = = = = = = = = = = = = = = = = = =

Thanks for reading, 

[1] https://wiki.eclipse.org/Neon/Simultaneous_Release_Plan
[2] https://wiki.eclipse.org/Neon/Simultaneous_Release_Plan#Schedule
[3] 
https://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.com=America/New_York
[4] 
https://support.google.com/calendar/answer/6285065?p=xml_deprecation=1



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

[cross-project-issues-dev] An apology to some, and a request to all ... please keep b3aggrcon files up to date.

[David M Williams]

I apologize if you were one of those that got spammed by several "build 
failed" messages Sunday night (Eastern) that did not make sense. That was 
the result of me "restoring" a test server and jobs running before I had 
time to customize them to not send mail. I think many such messages were 
stopped by spam filters, but not sure all of them were. 

My request: please make sure you keep your b3aggrcon files up to date, 
especially in the Mars_maintenance branch.  Several of those still refer 
to release candidate locations, which people have removed, or moved to 
release locations. So, there are several "real" (not spam) failures. It 
seems Neon (master) has a few similar errors. From some auto-reply 
messages I have been getting, may people are on vacation ... so, I hope in 
those cases there are backup people who can correct -- so if you are a 
"backup", please don't just assume the primary person will handle it. 

To help everyone achieve this goal -- of always being able to aggregate -- 
I have added a weekly, "periodic", aggregation to Mars (Mars_maintenance) 
and Neon (master). They are both Monday mornings, one at 8:15 and one at 
9:15 (Eastern). 

So, starting Monday morning (Eastern) if you get a "build failed" message, 
please pay attention to it and correct the problem (or, ask for help if 
you don't understand why its failing). 

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] Mars.1 Update Release is available

[David M Williams]

We have opened the repositories for Mars.1 Simultaneous Release updates 
[1] and EPP Package downloads [2]. 

As always, our greatest thanks to everyone who made this update possible. 


[1] http://download.eclipse.org/releases/mars/ 
[2] https://www.eclipse.org/downloads/


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