Skip to content

Meetings 2018 06 11

Greg Wilkins edited this page Jun 11, 2018 · 3 revisions

Eclipse EEJ4 Servlet-API kickoff: 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:

How does this work organisationally?

  • Who do we report to?

    • There is an ee4j PMC ee4j-pmc@eclipse.org
    • 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
  • How is the EE part coordinated?

    • Is there an eej4 architect?

How does this work technically?

  • Do we have/need a mailing list(s)?

  • 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?

More questions

- 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

Things to do:

  • 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?

Summary

We need to send these questions to the ee4j-pmc and get a few more answers before we run off in any particular direction.