-
Notifications
You must be signed in to change notification settings - Fork 87
Meetings 2018 06 11
DRAFT
Present:
- Stuart Douglas (Redhat) co-spec lead
- Greg Wilkins (webtide) co-spec lead
These are the minutes of the servlet-api kickoff meeting was held immediately after the initial code contribution of the servlet API has been made from oracle into the Eclipse-EE4J repository. The following topics were discussed, questions raised and decision made:
-
Who do we report to?
- There is an ee4j PMC [email protected]
- Will they be making technical decisions or just procedural?
-
Many of our questions need to be answered for ee4j collectively, as it would not be good for each group to do their own thing.
-
Do we have project/process mentors?
- We should direct all these initial questions to the eej4 PMC.
-
What is our scope?
- Initially we need to reproduce the servlet 4.0 api
- Are we also responsible for
- the servlet 4.0 document?
- The relevant xml schemas?
- The TCK?
- The reference implementation?
- Can we make ammendments to the 4.0 javadoc and specification in our initial releases? Ie can this be a maintenance release or does it have to be 1:1?
-
Do we recruit an EG?
- What rules will that operate under?
- Perhaps the IETF model of informal membership and rough consensus would work!
- Do we need an EG for 4.0? or just 4.1 and beyond?
- An EG would be good if we are doing a 4.0 maintenance release.
- Would be good to get an informal EG at least
- What rules will that operate under?
-
How is the EE part coordinated?
- Is there an eej4 architect?
-
Do we have/need a mailing list(s)?
- Probably YES
- What is [email protected]?
- Should that be [email protected]?
- Do we need a dev and EG mailing list?
-
Do we want everything on github (wiki meeting minutes etc.)
- Keeping most things on github would make sense as it would avoid other infrastructure.
- We should do what other groups do!
-
Who has commit access to the repo?
- Apparently others have commit access to the repo?
- Why can’t we see who has access?
-
Should we be review than commit?
- YES!
-
How do we do releases?
- Too soon to care!
-
How is the TCK going to be managed?
- Where will the resources be provided from?
- Do we need to worry about vendor independance?
- Probably NO
-
How is the specification document going to be managed?
- will it be in the same repo as the API?
- Is the source document available?
- What format should be used?
-
What is the plan for the reference implementation?
- Is it Glassfish?
- Will there be a servlet only reference implementation?
- Do we have to have one?
- Probably NO!
- We should put effort into good spec and good TCK and not into a reference implementation.
- Who provides resources?
- Do we want to build 3.1, 3.0 etc?
- Probably NO
- Do we manage our own schemas?
- Hopefully YES?
- Should the artifacts include the schemas?
- Preferably YES
- triage/label all the open issues
- Need to wait to know more about process/scope/architecture before triaging.
- copyright headers
- What do we change them to?
- Should an oracle committer do that?
We need to send these questions to the ee4j-pmc and get a few more answers before we run off in any particular direction.