Greetings specification committee
I would like to draw your attention to an update to the EFSP that we've been working on, that I've named "1.4 (DRAFT)".
I've described the significant changes in
a presentation.
As
we've stated in the presentation, our primary motivation is to extend
the EFSP to be inclusive of process specifications which, as
non-technical specifications, do not have things like TCKs (TCKs are
pretty deeply baked into the current revision). We're also taking the
opportunity to simplify where we can, and increase the flexibility to
support a broader range of domains, while keeping everything 100%
backwards compatible.
I believe that we've met
the goal to be 100% backwards compatible, in that we haven't added any
new requirements for existing projects. Upon adopting the new version,
however, some working groups may choose to restore some of the removed
elements and specific technical details to the working group
requirements.
I've published a draft of the update along with a diff:
The
final draft will also include some updates to conform with UK English
spelling and grammar. I've not included these updates in the documents
at this time to avoid adding unnecessary clutter.
I
ask that you please review the presentation and the documents. If you
have questions or concerns, please express them in this thread, or
(ideally) in the
issue that we created to track this effort (or create a new issue if that makes more sense to you).
While I have your attention, I'd like to remind you that we updated the
Eclipse Foundation Specification License to version 1.1 and Eclipse
Foundation TCK License 1.1. in October 2023 (Sharon sent a
note out at the time). The changes are primarily concerned with changing the copyright holder to the Eclipse Foundation AISBL.
Specification
projects should update to the new version of the license as soon as
possible. Projects that have already committed their Specification
Version artifacts for review do not need to rebuild and resubmit those
artifacts. We do, however, ask that you work with your projects to help
them adopt the new version of the license at their earliest convenience
(e.g., the next release).
Note also (and I
suspect that this will provoke some discussion), the license text should
not be changed. It is tempting to fill in the two copyright statement
templates that are present in the specification license, but these
should not be edited. Again, there's no need to recall projects that
have already been released; rather, let's think of this as something to
get right in the next release.
Thanks for your attention. Let me know if you have any questions.
Wayne
-- Wayne Beaton
Director of Open Source Projects | Eclipse Foundation
My working day may not be your working day! Please don’t feel obliged to read or reply to this e-mail outside of your normal working hours.
