| Re: [jakarta.ee-spec.committee] Jakarta EE 8 certification goal |
Wayne,
Two comments focused just on this Ratifying section.
- What is the difference in your mind between "ratify" and "approve"?
- Related, we had discussed the use of the word "adopt" at the place where you're using "ratify". Any particular reason why you went with a different term?
- In the legal discussions, the lawyers are discussing the idea of when a company participating in the spec process has its patents included in the output. The consensus is that we will have Reviews at certain steps along the way, and if a company is still involved in the spec group at the moment the Review is completed, then they've provided irrevocable patent license to the spec in its form at that time. This means that where you currently have Milestone 1 ... Milestone N there will need to be at least one, if not two Reviews under the EDP, along with an approval by the Specification Committee.
On 2018-05-08 3:44 PM, Wayne Beaton wrote:
Ratifying
The Specification Committee, then, is responsible for ratifying and promoting the output of the open source project's final release as an official specification. By the time we get to the point that a Specification Project makes an official release, the committee (and vendors) should have consumed milestone builds and provided feedback, so that final ratification step should be relatively straightforward.
So, I think that the spec creation and ratification process looks a little like this:
The project proposal includes a scope, so getting the Specification Committee's approval seems pretty natural.
Likewise, setting the plan at the beginning of a release cycle seems like something that the Specification Committee should get some say in. I tend to prefer a feedback loop model for milestone builds rather than formal approval (but am ready to be convinced otherwise).
Strictly speaking, the PMC approves releases, but we may decide to give the Specification Committee some say here. The main role of the PMC in the release process is to ensure that the process has been followed correctly and that the project is operating according to the open source rules of engagement.
Ultimately, the Specification Committee has to ratify (and promote) the specification.
In terms of coordinating the delivery of multiple specifications, our experience with the simultaneous release may provide some good answers. More on this later.
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee- spec.committee