Hi, Somehow the invite did not show up in my calendar for today’s special meeting, what is the Zoom link? The other one does not work. TIA Werner Sent from Mail for Windows 10 On Thu, Sep 13, 2018 at 9:14 AM, Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote: Votes. There is some disagreement regarding whether or not formalizing Participant votes is necessary/desired. The proposal at hand is that we require the committers on a Specification Project to engage in a positive vote before engaging the Specification Committee to either change the scope of a Specification Project or petition for the adoption of a final Specification Version.
We had decided that, if we adopt voting for final release or scope change at the project level, it would be the particapnts not the committers who vote. As I stated in the thread yesterday, my sense is that the vote is a "belts and suspenders" sort of thing. We don't need it (we have tacit approval by virtue of the various agreements that the Committers are required to sign or have signed on their behalf), but many among us feel that it's better if we have explicit approval.
You need approval of the member particpants not the committers. Participants. I think that I'd like to change "Specification Participant Representative" to "Member Participant Representative" for consistency. Any objections?
Scope of the process. I wrote that "only Compatible Implementations of Profiles that are certified by the Specification Committee may leverage the associated Brand". Bill suggested that this should not be a part of the process. We have discussed the focus of the process in the past, and I believe that it was decided that the EFSP stops at the point when the Specification Committee adopts a Specification Version. Do we have general agreement? If yes, then should we remove the "Branding and Certification" section and the various references to "Brand"?
Reviews. I've tried to generalize the notion of "Review". Am I trying too hard? Should we just define specific reviews (e.g. "Early Draft Review"). Can the Specification Committee also define the minimum and maximum time periods between reviews?
In the interest of progress we could requrie a review at least every 3 months from the start of the project. If a project fails to make progress at a reasonable rate, can the Specification Committee declare it to be "stalled"?
Yes. I would say that if it fails to make progress after 6 months that it be declared stalled. What does "stalled" mean? How long can a Specification Project be stalled?
What happens next? Specification Committee can decide to cancel the current release cycle iteration and kick the project back to planning, or some other form of remediation. In the extreme case, the Specification Committee can get the Project Leadership Chain to replace the project team.
Dependencies/references. In our discussion yesterday regarding profiles, the notion of dependencies (references between specifications) was introduced. AFAICT, this isn't formalized by the JCP. How Specifications are combined feels like an important concept. Having said that, I'm not sure if the concept needs to be formalized in the EFSP beyond the requirement that a Profile be "complete". The JCP's statement that "Other referenced Specifications must be referenced in their entirety" doesn't, IMHO, make the intention clear enough; what, specifically, does "referenced" mean? I believe that what's intended is that an implementation of a Profile must be complete enough to drop on a runtime, configure, and go (I'm obviously oversimplifying). In contrast, an implementation of a Specification could require that the adopter gather implementations of a bunch of other specs, and then assemble and deploy them themselves. I'm pretty sure that this is what Bill stated on yesterday's call.
I like to think of a Profile as a kind of complete platform. It may be a subset of an existing platform or a super set but either way, the TCK to test compliance should require a complete solution as defined by the profile. Random... any objection to referencing RFC 2119? (this is paraphrased in the JCP) The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
-- Wayne Beaton Director of Open Source Projects
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
