You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 24, 2023. It is now read-only.
Some specification projects, e.g., OSGi Specification include specifications, TCKs, and implementations in the same project. In the case of the OSGi Specification project, they're all actually in one single Git repository. Factoring that into separate Git repositories owned by separate projects would likely be onerous, and provide no incremental value.
The Eclipse Foundation Development Process supports the notion of releasing a project in parts. Theoretically, a specification project could, then, create many releases of an implementation without creating any new final specifications. Were these implementations part of a regular Eclipse project, they would have to engage in a review only annually.
I took only a quick look at the IP Policy. I believe that it supports a notion of a specification project releasing non-specification content without a release review.
e.g.:
Pursuant to the Eclipse Foundation Specification Process, each Specification Project will have a series of Check Point Reviews prior to the publication of a Final Specification.
I'm interpreting this to mean that a review (a release review is a kind of check point review) is only required when the release includes a new final specification. I'll need to have a closer look to make sure that there are not other "gotchas".
The EFSP more tightly couples Specification Projects and releases.
e.g.:
Reviews are required for all Releases of a Specification Project.
We may be able to squint and say that this doesn't apply to implementations released by a specification project, and the removal of the requirement for release reviews for service releases (#29), may actually make this a non-problem; but it would be better to make this as clear as possible. This needs to be fixed and now seems like a good time to fix it.
Some specification projects, e.g., OSGi Specification include specifications, TCKs, and implementations in the same project. In the case of the OSGi Specification project, they're all actually in one single Git repository. Factoring that into separate Git repositories owned by separate projects would likely be onerous, and provide no incremental value.
The Eclipse Foundation Development Process supports the notion of releasing a project in parts. Theoretically, a specification project could, then, create many releases of an implementation without creating any new final specifications. Were these implementations part of a regular Eclipse project, they would have to engage in a review only annually.
I took only a quick look at the IP Policy. I believe that it supports a notion of a specification project releasing non-specification content without a release review.
e.g.:
I'm interpreting this to mean that a review (a release review is a kind of check point review) is only required when the release includes a new final specification. I'll need to have a closer look to make sure that there are not other "gotchas".
The EFSP more tightly couples Specification Projects and releases.
e.g.:
We may be able to squint and say that this doesn't apply to implementations released by a specification project, and the removal of the requirement for release reviews for service releases (#29), may actually make this a non-problem; but it would be better to make this as clear as possible. This needs to be fixed and now seems like a good time to fix it.
/cc @paulbuck
/cc @bjhargrave
By way of background, BJ, I'm drafting an update to the EFSP (see #33). I'll contact you via email with more information shortly.
The text was updated successfully, but these errors were encountered: