Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Updates to the Eclipse Foundation Specification Process


On Mon, Sep 10, 2018 at 4:33 PM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
Wayne Beaton wrote on 9/10/18 2:13 PM:
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").
 Sounds good.
 
+1
 



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:
  • Is a member of the Eclipse Foundation, either as a Member Company or as an individual Committer Member;
  • Has signed a Working Group Participation Agreement; and
  • Has at least one committer on the Specification Project (or is a committer on the Specification Project in the case of a Committer Member).
 So for a Member Company, it's the Company that's the Participant, not the individual representing the company, right?  I know in the JCP process document it got confusing when sometimes the participant meant the company and sometimes it meant the individual, and we have to rewrite some sections to make it clear.  We'll need to check the EFSP document to make sure it doesn't have any of these problems.

I agree. A clear distinction between participant and committer is needed.  My understanding is that an company or an individual can be a representative but can a company be a committer or is the representative of the a company that is the committer?
 


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.
-1 
 I understand why companies want control over who represents their interests.  What's the motivation for an individual doing the same?

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.
 I agree.

+1
 



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.
 I agree.

+1
 



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)

-1
 
 I would not allow subsetting in this way.


Compatible Implementations at the Eclipse Foundation
Have we agreed that there is a requirement that at least one open source implementation be hosted a Eclipse Foundation? Should that requirement be included in the document?
 That would be a problem for CDI, BV, and Batch.


This should not be a requirement.  Eventually, I want to see the open source implementations under EF separated from the Specification project. Breaking up the EE4J into a open source code that implements Jakarta EE and the Jakarta EE Specification.  This would hamper that transition.

 


_______________________________________________
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


Back to the top