Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

At the risk of being vague and handwavy... The requirement is that the contents of the packages *come through the simultaneous release*. That is, Eclipse JustJ needs to participate in the simultaneous release as participation is defined by the Planning Council. It's not clear to me whether or not

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

Hi Wayne, Where does JustJ fit in here? JustJ is part of the simrel, but not part of the aggregated content on simrel? Is it still OK for EPP to consume JustJ in that way? Thanks Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Fri, 22 Jan 2021 at 10:23, Wayne Beaton <

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

There is no context in this post... Note that the train contents themselves should be signed, not just those things actually used in the packages.    Here's what happens when that's not the case: https://www.eclipse.org/forums/index.php/mv/msg/1106767/1837377/#msg_1837377 Such a problem is

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

This also prevents from shipping the PDE/Maven integration by default in packages because it contains BND artifact (unmodified from Maven) that is not signed with the Eclipse certificate. ___ cross-project-issues-dev mailing list

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

> That's up to them but they're not pushing that sort of requirement out to everyone else. You're right. They're not. Why are we arguing? Wayne On Sat, Jan 23, 2021 at 9:42 PM Jesse McConnell wrote: > Security model for artifacts in Maven Central is sufficient for most of > the known world,

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

Security model for artifacts in Maven Central is sufficient for most of the known world, and if the eclipse foundation was interested in signing the keys of committers then the artifacts that committers from the eclipse foundation published to Maven Central could have a web of trust associated

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

Hi Jesse, To paraphrase Wayne, in short: the Eclipse Foundation has a responsibility in making sure that the community can trust every bundle they consume from the simultaneous release. What we currently do is to sign these bundles with a certificate from the Eclipse Foundation. This is a

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

> *All bundles must be signed using the EF's certificate. *Obvious >> exceptions will be made in cases where signing is impossible. >> > >> We will be applying this standard to the next release and for every >> release thereafter. >> >> The means by which the simultaneous release participation

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

[cross-posted to epp-dev mailing-list] Hi, That means that the "Eclipse IDE for Rust developers" package should not appear on the https://www.eclipse.org/downloads/packages/ page. To be honest, it's not a big deal, I'll adjust links from Corrosion README so they point to the internal EPP download

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

On Fri, Jan 22, 2021 at 5:23 PM Wayne Beaton < wayne.bea...@eclipse-foundation.org> wrote: > As the recent SolarWinds hack has reminded us, security is everyone's > concern. We owe it to the millions of developers and adopters who use our > technologies to take all reasonable steps to ensure the

[cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

As the recent SolarWinds hack has reminded us, security is everyone's concern. We owe it to the millions of developers and adopters who use our technologies to take all reasonable steps to ensure the validity of the software that we distribute. Responsibility to decide which Eclipse IDE packages

Re: [cross-project-issues-dev] Simultaneous Release Participation

Thanks for the update, Tom! Then, I will update the GEF target to include 3.5.0 and run another build. Is it okay to wait for the removal before updating the GEF contribution or do I need to update the GEF contribution first? Best regards, Matthias -- Matthias Wienand B.Sc. Softwaretechnik

Re: [cross-project-issues-dev] Simultaneous Release Participation

Hi, I would strongly advise to use 3.5.0 release who is available since yesterday! Only this releases eg supports Java-11 and JavaFX-11 but in the end it is up to you what you include. You should never ship 3.3.0 because it will make Eclipse IDE crash when running on Java-11! Tom On 01.03.19

Re: [cross-project-issues-dev] Simultaneous Release Participation

Hi, I added an entry for the required e(fx)clipse feature to the category.xml as follows: http://www.xing.com/profile/Matthias_Wienand2 http://www.itemis.de itemis AG Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.),

Re: [cross-project-issues-dev] Simultaneous Release Participation

Hi Matthias, Did you have a chance to look at the required changes for GEF? We can't remove the e(fx)clipse contribution without those changes. Regards, Fred On 19.02.19 16:47, Matthias Wienand wrote: > OK, > > I will try to resolve this at the start of next week and report back. > > Best

Re: [cross-project-issues-dev] Simultaneous Release Participation

I just pushed a Gerrit review that removes Eclipse e(fx)clipse and Eclipse Code Recommenders from the Simultaneous Release Repository. I've updated the release page . I've made my best guesses at release

Re: [cross-project-issues-dev] Simultaneous Release Participation

Hi Wayne, > After some churn, Eclipse Code Recommenders ended up in 2018-12, but is > now marked as disabled. What is the participation status for this > project in 2019-03? I think Code Recommenders is currently lacking the manpower to join the release train again. In fact, I'm afraid I will

Re: [cross-project-issues-dev] Simultaneous Release Participation

OK, I will try to resolve this at the start of next week and report back. Best regards, Matthias -- Matthias Wienand B.Sc. Softwaretechnik Software Engineer Telefon: +49 231 9860 202 Telefax: +49 231 9860 211 Mobil: +49 152 26802283 matthias.wien...@itemis.de

Re: [cross-project-issues-dev] Simultaneous Release Participation

On Tue, Feb 19, 2019 at 5:41 PM Matthias Wienand wrote: > Hi, > > it is not yet clear to me how to proceed. I could imagine that a version > is made available via Orbit. > Orbit is not meant for eclipse.org projects. > Otherwise, I believe we would need to include what is needed in GEF >

Re: [cross-project-issues-dev] Simultaneous Release Participation

Hi, it is not yet clear to me how to proceed. I could imagine that a version is made available via Orbit. Otherwise, I believe we would need to include what is needed in GEF directly. What do you think? Best regards, Matthias -- Matthias Wienand B.Sc. Softwaretechnik Software Engineer

Re: [cross-project-issues-dev] Simultaneous Release Participation

Thanks Tom. Eclipse e(fx)clipse consumers: have you sorted out how to react to the removal? Wayne On Tue, Feb 19, 2019 at 10:20 AM Tom Schindl wrote: > Hi, > > Yes - i know I'm behind schedule. We are still droping from the release > as announced earlier. Feel free to remove/deactivate us. >

Re: [cross-project-issues-dev] Simultaneous Release Participation

Hi, Yes - i know I'm behind schedule. We are still droping from the release as announced earlier. Feel free to remove/deactivate us. Tom On 19.02.19 16:15, Wayne Beaton wrote: > I'm a little overdue updating the participation page. I'm trying to get > that sorted out today. > > Let this serve

Re: [cross-project-issues-dev] Simultaneous Release Participation

One additional important deadline is: March 01/2019 - Milestone 3 IP Log submission deadline Dani From: Wayne Beaton To: Cross project issues Date: 19.02.2019 16:16 Subject:[cross-project-issues-dev] Simultaneous Release Participation Sent by:cross-project-issues

[cross-project-issues-dev] Simultaneous Release Participation

I'm a little overdue updating the participation page. I'm trying to get that sorted out today. Let this serve as your notice that the RC1 date (March 8) is coming quickly. Dani updated the page to note that this is the "API and feature freeze" date. If you need to engage in a release review, then

Re: [cross-project-issues-dev] Simultaneous Release Participation

Hi Wayne, I have a clarification question here. The wiki page states that the corresponding release record must exist before the M1 date. What happens if a project would like to update the contributed release number after M1 with a different bugfix release? As a more concrete example, VIATRA

[cross-project-issues-dev] Simultaneous Release Participation

Hey Folks. I've tried to capture the new opt-in process. I appreciate your input (and will take this opportunity to remind you that it is a wiki). https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#State_intent_early I've changed the header which adversely impacts existing links

[cross-project-issues-dev] Simultaneous release participation

Greetings folks! The list of projects participating in the Juno release is here [1]. Note that only projects that have flipped the "juno" bit in the simultaneous release field in the project metadata are shown. If your project is participating, you need to flip the