Re: [platform-dev] Eclipse and Equinox 4.29 (2023-09) GA is available
It looks like the Eclipse project forgot to create a release record for 4.29: https://projects.eclipse.org/projects/eclipse/governance I did ask folks to review their release records, and to create new ones where appropriate, well ahead of when Wayne created the PMI page on this issue: https://github.com/merks/simrel-maven/issues/9 On 14.09.2023 14:25, Jan Westerkamp via platform-dev wrote: Great news! But I wonder about the deviation of the contained project version numbers included in Eclipse 2023-09 (https://projects.eclipse.org/releases/2023-09): - Eclipse Project 4.28.0 (https://projects.eclipse.org/projects/eclipse/releases/4.28.0) - Eclipse Packaging 4.29.0 (https://projects.eclipse.org/projects/technology.packaging/releases/4.29.0) This originated the following issue for the Homebrew packages: https://github.com/Homebrew/homebrew-cask/issues/155163 Is this deviation intended or a bug? Best, Jan Am 13.09.23 um 16:00 schrieb Rahul Mohanan via platform-dev: Hello Everyone, We are pleased to announce that 2023-09 is available for download and updates. Eclipse downloads: https://download.eclipse.org/eclipse/downloads/drops4/R-4.29-202309031000/ New and Noteworthy: https://www.eclipse.org/eclipse/news/4.29/ Update existing (non-production) installs: https://download.eclipse.org/eclipse/updates/4.29/ Specific repository good for building against: https://download.eclipse.org/eclipse/updates/4.29/R-4.29-202309031000/ Equinox specific downloads: https://download.eclipse.org/equinox/drops/R-4.29-202309031000/ Thank you to everyone who made this checkpoint possible. Thanks and Regards, /Rahul Mohanan/ Eclipse SDK Team ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] Eclipse and Equinox 4.29 (2023-09) GA is available
All the update sites are sound and have the correct content. The only problem is that this link does not exist because someone overlooked creating it: https://projects.eclipse.org/projects/eclipse/releases/4.29.0 As a result, this mostly-generated page cannot point to it: https://projects.eclipse.org/releases/2023-09 But these sites have the correct content: https://download.eclipse.org/eclipse/updates/4.29/ https://download.eclipse.org/releases/2023-09/ Also, all the links in Rahul's email are correct and have the 4.29 content for the 2023-09 release. I don't know anything about Homebrew or what the discussion there is about. In any case, release records on projects.eclipse.org are not relevant with respect to the actual released content which is correct as it is now and is not in need of fixing. On 14.09.2023 18:33, Jan Westerkamp via platform-dev wrote: Hi Ed, does this mean only the organisational things and the site needs a fix or does this mean a patch release (i.e. 4.29.1 with updated release notes etc.) is required to fix this? So does this need to be fixed before the Homebrew issue can be fixed (the existing version only references an invalid version number "4.28.0,2023-09", but should download 2023-09)? If not, then the Homebrew side can be fixed now and does not need an additional fix later, which would create inconvenience because additional configs and plugins need to maintained by the users again. Best, Jan Am 14.09.23 um 14:33 schrieb Ed Merks via platform-dev: It looks like the Eclipse project forgot to create a release record for 4.29: https://projects.eclipse.org/projects/eclipse/governance I did ask folks to review their release records, and to create new ones where appropriate, well ahead of when Wayne created the PMI page on this issue: https://github.com/merks/simrel-maven/issues/9 On 14.09.2023 14:25, Jan Westerkamp via platform-dev wrote: Great news! But I wonder about the deviation of the contained project version numbers included in Eclipse 2023-09 (https://projects.eclipse.org/releases/2023-09): - Eclipse Project 4.28.0 (https://projects.eclipse.org/projects/eclipse/releases/4.28.0) - Eclipse Packaging 4.29.0 (https://projects.eclipse.org/projects/technology.packaging/releases/4.29.0) This originated the following issue for the Homebrew packages: https://github.com/Homebrew/homebrew-cask/issues/155163 Is this deviation intended or a bug? Best, Jan Am 13.09.23 um 16:00 schrieb Rahul Mohanan via platform-dev: Hello Everyone, We are pleased to announce that 2023-09 is available for download and updates. Eclipse downloads: https://download.eclipse.org/eclipse/downloads/drops4/R-4.29-202309031000/ New and Noteworthy: https://www.eclipse.org/eclipse/news/4.29/ Update existing (non-production) installs: https://download.eclipse.org/eclipse/updates/4.29/ Specific repository good for building against: https://download.eclipse.org/eclipse/updates/4.29/R-4.29-202309031000/ Equinox specific downloads: https://download.eclipse.org/equinox/drops/R-4.29-202309031000/ Thank you to everyone who made this checkpoint possible. Thanks and Regards, /Rahul Mohanan/ Eclipse SDK Team ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] Problems installing Platform using Oomph
It's fixed by this: https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/1429 This job promoted the changes: https://ci.eclipse.org/oomph/job/setup-archiver/ So the server should very soon yield the changes for the installer to work properly. Locally you should do a pull on all the git repositories, especially of course the aggregator repository, to see this change when you do Help -> Perform Setup Tasks... Thanks for reporting! And sorry for the inconvenience. On 09.10.2023 12:58, John MOULE via platform-dev wrote: Hi, I'm using Oomph installer to install Eclipse SDK with Platform project. But I get the following error: ERROR: org.eclipse.equinox.p2.metadata.repository code=1000 No repository found at https://download.eclipse.org/webtools/CI/3.31.0/I-latest/repository. (details attached) I've tried using "Latest Release (4.29 - 2023-09)" and "Latest (4.30 - 2023-12)", but get the same results. Windows 10, JDK 17.0.5 Am I missing something or is this a known issue? Cheers John ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] Process for a security/bugfix release for the Eclipse Platform
Marta, I notice this interesting blog has relevant background details: https://newsroom.eclipse.org/eclipse-newsletter/2023/may/reporting-and-managing-security-issues-eclipse-foundation-projects With respect to timing, I see this in the policy: https://www.eclipse.org/security/policy/#timing With respect to distribution of a resolution, I do not see the use of, nor definition of, the term "security release" but rather only the following, where it simply mentions using "normal distribution channels" at a minimum: https://www.eclipse.org/security/policy/#distribution In general, all changes are normally made available for distribution within a day via integration builds, and, as you've noted, releases are normally made available for distribution on a quarterly basis. Also highly relevant, is that the simultaneous release, the mostly widely used distribution channel, is also normally available quarterly. SimRel integration (staging) builds are available daily with new content available as contributed by the participating projects: https://ci.eclipse.org/simrel/ Asking for special out-of-band "security releases" is asking for a lot from the Platform project. Too much in my *personal opinion*, but everyone is entitled to an option. Moreover, I assume this same policy, and expectation, applies uniformly for all projects where that expectation is probably significantly less realistic. It would seem better to me to try to work (as much as possible) within the bounds of the existing processes and normal distribution channels. General cross-cutting discussions or issues can be hosted here: https://github.com/eclipse-platform/.github/discussions https://github.com/eclipse-platform/.github/issues This related discussion is already underway: https://github.com/eclipse-platform/.github/discussions/129 Regards, Ed On 18.07.2023 18:03, Marta Rybczynska via platform-dev wrote: Hello, Eclipse platform has been releasing every three month for some time. I've been recently working on clarifying security processes and I could not find a description how the Eclipse Platform handles a security release. Would a security fix need to wait for next 3-month release? This could be in conflict with the 90 days vulnerability release policy. Consider this scenario: - A vulnerability is reported two weeks before the release and the team needs some time to prepare a fix. - The fix is ready one month after the release - 90 days will come two weeks BEFORE the next release Releasing a vulnerability information to the public without a release fixing it is against best practices and it would be beneficial to avoid it. Do you consider running a separate bugfix release? Could you please point me to documentation/discussions on how you do handle or would handle such a situation? Thanks in advance, Marta ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] Process for a security/bugfix release for the Eclipse Platform
Marta, Note that all the opinions I express are *my own*. I *do not *speak for the Platform. My opinions reflect the reality of the great many projects supported by a handful of committers (or even a single committer) doing everything on a for-free basis. While the focus here right now may be on the Platform's set of projects, that focus will (must?) eventually broaden to include all of SimRel (and effectively all Eclipse Projects and all their dependencies) because security problems can come from anywhere and from any Project. I would hope that most projects could produce a new build on short noticed, but I know that even that's unfortunately (and shockingly) not the case. Certainly the Platform is more than capable of producing a build on a moment's notice, and such a build (p2 update site) could be termed an "emergency release", but I think you probably are using that term to mean something much more. In any case, please don't get me wrong. I fully share the Foundation's concerns about loss of reputation and the Foundation's goal of being an industry leader. The reality though is that the Foundation has a budget while Projects don't. I believe that probably I speak for most of the Platform committers when I say that I prefer this discussion on a GitHub issue or GitHub discussion. Likely no one wants a long disconnected set of email threads on such a topic, and after the fact, someone will likely want a single location with a cohesive thread of discussion rather than a disjointed mailing list archive. I wonder if the focus on the Platform is a bit of the case of looking for a lost set of keys under the streetlight because the lighting is best for finding lost things there. It's just as likely that the keys will be lost in some dark corner, or deep in the grass. But I suppose one has to start looking somewhere. This issue is also very likely of interest to the IDE Working Group, which also has a budget... Regards, Ed On 24.07.2023 09:25, Marta Rybczynska wrote: Hello Ed and others, The policy of EF reflects the reality in the industry. 90 days is the typical time security researchers agree to wait. However, this is not set in stone. It might happen that a researcher says they have a presentation accepted on a conference and they will present the vulnerability at that specific date. Or, a researcher who is following a different calendar, like 30 days. Or if there is an active exploitation of a vulnerability. In such cases, if the project does not have a way to produce an emergency release in such cases, this could be bad for their users (and their reputation...). This is the risk I note in this case (EF policy is secondary here). Also, this is also always a project's call to decide to do a security release or not. Usually, for a minor vulnerability, it is OK to wait. For a major one, it's another story. It might be useful to start a discussion about cross-project security releases (we call it coordinated disclosure in the security world, btw), do I read it correctly that you prefer a GitHub issue instead of a mailing list post? Kind regards, Marta On Wed, Jul 19, 2023 at 9:31 AM Ed Merks via platform-dev wrote: Marta, I notice this interesting blog has relevant background details: https://newsroom.eclipse.org/eclipse-newsletter/2023/may/reporting-and-managing-security-issues-eclipse-foundation-projects With respect to timing, I see this in the policy: https://www.eclipse.org/security/policy/#timing With respect to distribution of a resolution, I do not see the use of, nor definition of, the term "security release" but rather only the following, where it simply mentions using "normal distribution channels" at a minimum: https://www.eclipse.org/security/policy/#distribution In general, all changes are normally made available for distribution within a day via integration builds, and, as you've noted, releases are normally made available for distribution on a quarterly basis. Also highly relevant, is that the simultaneous release, the mostly widely used distribution channel, is also normally available quarterly. SimRel integration (staging) builds are available daily with new content available as contributed by the participating projects: https://ci.eclipse.org/simrel/ Asking for special out-of-band "security releases" is asking for a lot from the Platform project. Too much in my *personal opinion*, but everyone is entitled to an option. Moreover, I assume this same policy, and expectation, applies uniformly for all projects where that expectation is probably significantly less realistic. It would seem better to me to try to work (as much as possible) within the bounds of the existing processes and normal distribution channels. General cross-cutting
Re: [platform-dev] Add Upstream REPO
This all appears to be completely general questions about git and nothing specific to do with the Eclipse Platform, so likely best asked elsewhere such as stackoverflow. If you must ask questions (related to the Eclipse Platform) it's better to use discussions not the mailing list https://github.com/eclipse-platform/.github/discussions We all get too much email already... On 06.12.2023 10:50, java joe via platform-dev wrote: Im following the directions in; https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-repository-for-a-fork QUESTION: in number 3 below, WHAT would be the |*ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git *IS that the main trunk? As in; https://github.com/eclipse-platform/eclipse.platform.git ANY HELP GREATLY appreciated. Im trying to update my fork to the trunk and not doing so hot.. | 1. Open Terminal. 2. List the current configured remote repository for your fork. |$ git remote -v > origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch) > origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (push) | 3. Specify a new remote /upstream/ repository that will be synced with the fork. |git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git | 4. Verify the new upstream repository you've specified for your fork. |$ git remote -v > origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch) > origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (push) > upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (fetch) > upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (push) | ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] How to build SWT jars from sources?
Yes, that seems like the most focused place https://github.com/eclipse-platform/eclipse.platform.swt/discussions Unfortunately Hannes just started vacation, so help might be in short supply. I imagine you just need to clone SWT including the LFS parts of the repository and redirect your scripts to that folder location. Good luck! On 23.02.2024 14:31, Thomas Singer via platform-dev wrote: What would be the SWT discussion list? How to build the SWT jars using ANT? ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] How to build SWT jars from sources?
It's probably better to ask on one of the discussions list. The binaries are in the SWT repository https://github.com/eclipse-platform/eclipse.platform.swt/tree/master/binaries but you need to enable the LFS support for those be be checkout out as they are in the workspace with the Oomph setup: On 23.02.2024 09:17, Thomas Singer via platform-dev wrote: Hi Jonas, Thanks for answering. The linked comment writes about building the native fragments which is not what I want. I need to build the SWT jars which until recently used the prebuilt native fragments from org.eclipse.swt.binaries. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
