Update and simplify the simrel requirements #49
Conversation
merks
commented
Apr 30, 2025
- Remove all records release records and so on with a single requirement to follow the EDP; many projects, including the Platform, have not been creating release records and pretty much no one has any formal plans.
- Remove reference to plug-ins without a MANFIEST.MF; those are long gone.
- Clarify the third-party requirements to reflect how it is currently actually working and what is currently actually allowed and disallowed.
|
I'd like to propose the following changes to the SimRel requirements for review by the Planning Council. I think there are more changes that we should make, but I wanted to limit the scope for this pass. If you are both okay with this, we can ask the Planning Council for approval... |
|
FYI, I reused the Platform's new website infrastructure to render the SimRel wiki markdown: https://eclipse.dev/eclipse/markdown/?file=eclipse-simrel/.github/main/profile/README.md |
824b4fc to
cd30591
Compare
cd30591 to
8364ec7
Compare
There was a problem hiding this comment.
The proposed changes are fine to me. I will ask the Planning Council members to have a look at the proposal before the upcoming meeting so that we can agree on the proposal in that meeting.
I just have two questions:
- I find some of the requests regarding release records actually useful, such as the specification of supported target environments. But if I understand correctly, we propose to just make it up to the project which exact requirements specifications they make as long as it fits to the EDP, right? So for the Platform project we may just keep providing such specifications if we consider them useful. Regarding the comment that not even the Platform has a release record, I wonder if the "project plans" we have aren't basically release records, such as for the 4.36 release: https://eclipse.dev/eclipse/development/plans.html?file=plans/eclipse_project_plan_4_36.xml&crumb=4.36
- If we agree on this, should we then remove some of the according information from the individual release schedules (like https://github.com/eclipse-simrel/.github/blob/main/wiki/SimRel/2025-06.md), such as the due dates for release record creation, IP Log submission and release review materials?
It's not so much a question to me of whether the release records are useful, it's a question of whether they should be required when then are not required by the EDP and when release reviews are gradually being phased out in favor of progress reviews. I'm not sure exactly what you intend to denote by "supported target environment" but generally the Platform is the only project with os/ws/arch fragments so from that respect there is not so much to document. The target EE is covered by this section that remains: And in the end, no one is required to support a version of the Platform older than the current one while everyone is required to support that one.
Yes. Of course saying you must obey the law/rules arguably goes without saying, but when spelling out rule details beyond that, we should consider primarily, "how does this rule improve SimRel"? In any case, the Platform has not been producing release records and has not had a review in the last 3 years, so technical it's not really following the EDP...
Given the Platform is at the root and given the Platform is consumed directly as well, documentation is a very good thing.
Yes, there is a plan, but that's not a release record. Moreover the current rule requires the record to be produced at the start of the development cycle. No one is doing that. Worst yet, if you look at these records, you'll find they are very short on useful details to the point of being useless: https://projects.eclipse.org/releases/2025-03
Yes, that's the point. But removing more things will make sense only once we agree to remove the requirements for them and this requirements document is the only one moderated by the Planning Council, so I want any changes here reviewed and approved by the Council. There are more simplification I think would be good, but one step at a time. There is no point in having rules that are not being followed and no point in having rules that are not focused on what SimRel really requires in order to function well. We have a lot of experience and these documents were created long ago before we were consistently producing releases every 3 months... |
|
Thank you for all the additions! I agree with everything said. In particular these points phrase well why we should reduce the detailed requirements:
Regarding "supported target environments":
I was referring to that exact section. But you are right, Platform is basically the project introducing the requirements regarding the environments. I think it's just important that we clearly state which environments we support (in particular which versions of the three major OSes) as that's a recurring topic of discussion and complains. So having that precisely stated makes sense, but, as you said, that information will just remain. |
There was a problem hiding this comment.
Changes are fine from my side.
In today's planning council meeting, we agreed on giving time for objections by the planning council members until end of May 8th and consider the proposed change approved by the planning council in case there are no objections by then.
| > Projects may push out releases for a full calendar year following a successful Release Review or a Progress Review. | ||
| > Note also that this does not excuse the project team from the obligations of the Eclipse IP Policy | ||
| > all intellectual property must be fully vetted before it may be included in any release. | ||
| Project are required to follow the |
There was a problem hiding this comment.
| Project are required to follow the | |
| Projects are required to follow the |
| and distributed with a bundle symbolic name | ||
| that has the potential to conflict with a bundle symbolic name used by another project. | ||
|
|
||
| The Simultaneous Release must avoid unnecessary duplicate third-party libraries. |
There was a problem hiding this comment.
👍
@merks: Could we add a link here to the SimRel content overview that you prepare for M1/M2 where participating projects can easily see the current state of things?
- Remove all references to release records and so on with a single requirement to follow the EDP; many projects, including the Platform, have not been creating release records and pretty much no one has any formal plans. - Remove reference to plug-ins without a MANFIEST.MF; those are long gone. - Clarify the third-party requirements to reflect how it is currently actually working and what is currently actually allowed and disallowed.
8364ec7 to
afa27b7
Compare
|
"Failing 429 links" manually verified to be working correctly. |