Skip to content
This repository has been archived by the owner on Mar 24, 2023. It is now read-only.

Reviews and ballots are only required for releases of specifications #44

Open
waynebeaton opened this issue May 10, 2021 · 0 comments
Open

Comments

@waynebeaton
Copy link
Contributor

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.

/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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant