| Re: [jakarta.ee-spec.committee] Updates to the Eclipse Foundation Specification Process |
|
Apologies but there will be no one from Payara at the spec or steering calls as I have a family commitment this evening and Arjan is on holiday. Steve From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Wayne Beaton Greetings Jakarta EE Specification Committee members! I've made some updates to the draft
Eclipse Foundation Specification Process document based on our discussions on the last call. Primarily, these updates are concerned with consolidating on the term "Compatible Implementation" and removing references to "Specification Implementation" and
changing "Independent Implementation" from a defined term to a notion (e.g. "independent Compatible Implementation"). I'd like to focus tomorrow's discussion on the following topics. I'm going to recommend that we limit discussion on each topic to 15 minutes each. Participation I think that what is intended is that a "Participant" in a particular Specification Project:
Does an individual Committer Member have the same ability to appoint a Committer representative as a Member Company? i.e. can a Member Committer who has signed the corresponding Working Group Participation Agreement have the ability
to appoint themselves as a committer on a Specification Project? If yes, then we'll need to reassert the "Member Participant" definition that I've removed. I'm expecting that the term "Member Participant" might be important in other documents/references. Subsetting Let's avoid technical considerations (e.g how to implement/run/interpret the TCK) in the process document. For the purposes of the process document, it's enough to say "must comply with the TCK" (or equivalent) and leave the rest as implementation
detail to be sorted out by the individual Working Groups. If you disagree with this statement, let me know and we'll table that discussion for a later session. I had been pushing for a call regarding whether or not we want to make the notion of subsetting explicit in the document. Note that there are two different examples of subsetting: (1) an implementation of a part of a Specification, or (2)
a Specification (or Profile) that requires that only some subset of another Specification be implemented. The first example is a full-stop no: a Compatible Implementation must implement all required parts of a Specification Version. The case where a Specification Version requires that all but the optional parts of another Specification Version be implemented is okay and doesn't, I think, require further discussion. Similarly, the case where a Specification Version
requires that the required and some optional parts of another Specification Version be implemented is okay. If Specification A requires that some, but not all of Specification B be implemented, then it's possible to have a Compatible Implementation of Specification A while having an incompatible implementation of Specification B. Is this okay?
i.e. Does the implementer get access to the patents from Specification B if they don't fully implement that specification? (no?) Does the implementer of Specification A get access to the brand if they don't fully implement Specification B? (probably) Compatible Implementations at the Eclipse Foundation Thanks,
-- Wayne Beaton Director of Open Source Projects The Eclipse Foundation |