Date: 2020-01-14
Present:
- Ivar Grimstad (Eclipse Foundation)
- Kevin Sutter (IBM)
- Scott Marlow (Red Hat)
- Paul Nicolucci (IBM)
- Jonathan Gallimore (Tomitribe)
- David Blevins (Tomitribe)
- Rhuan Rocha (Red Hat)
- Steve Mllidge (Payara)
- Carlos Andres De La Rosa (Eclipse Foundation)
- Scott Stark (Red Hat)
- Andy McCright (IBM)
- Martin Stefanko (Red Hat)
- Kenji Kazumura (Fujitsu)
- Bill Shannon (Oracle)
- Dmitry Kornilov (Oracle)
- Brian Stansberry (Red Hat)
- Alessio Soldano (Red Hat)
Agenda
- What do we need to track to measure progress of other projects?
- How do we track it?
- What artefacts does this project need to create?
- How do we track those?
- Any volunteers to do them?
- [KWS] https://github.com/orgs/eclipse-ee4j/projects/17
- Would like an [Epic] label assigned to each Issue.
- Would also like a [wave:n] label assigned to each issue based on the info in this sheet: https://docs.google.com/spreadsheets/d/1EN5UEzxFV1Buk7yqdQAweaynWJ3UNn2BjN7blXn9vh4/edit#gid=0
- Already getting some activity on the generated Issues. Thank you!
- Please help with keeping the Epic Issues and the Project Board up-to-date. Thanks again!
Kevin walked us through the project board and the “epic issues”.
There is one epic per specification that needs to be updated.
Each epic issue contains a checklist for tasks needed for the release.
If a component specification does not add anything other than what is specified in the overall platform release plan, there is no need to create a release record and engage in a plan review.
Those components adding functionality will need to create a release record on its own.
- Major release -> Type B Due Diligence Type
- Minor release -> Type A Due Diligence Type
Discussed the need for progress review. The process does not require this.
Release review ballots must be started for components that are ready as soon as possible.
Committers on individual component specifications are strongly encouraged to help with keeping the status correct in the project tracking board.
Schema namespace needs to be determined and established. (Ivar/Kevin)
Tutorials and Samples will eventually need to be updated to support Jakarta EE 9. (Encourage community involvement.)
API jars must be versioned using major.minor.patch version number. That is three digits. Example: 3.0.0
