-
Notifications
You must be signed in to change notification settings - Fork 4
Priorities
For a couple starting points into this discussion, see:
-
Various public ML discussions, e.g. this post and some recent ones before.
-
Some ideas and proposals in this document.
-
Some more history in this spec issue
In bugzilla, the SPEC component will be used to hold all spec issues:
-
clarifications
-
corrections
-
brand new ideas
-
elaborations
You get the picture.
Use this Bugzilla query to see the unresolved items.
A goal is to get the TCK documentation (in the form of contributor’s guides, etc.) to the point where people could reasonably be asked to contribute a TCK test along with a new spec issue (or at the least some portion of the test).
To open your own new issue, click here.
In bugzilla, the TCK component will hold spec issues that still need enforcement added in TCK.
After a spec issue is agreed upon and documented its component field will be changed to TCK reflecting the need to still add a test in the TCK.
The RI may still need updating as well. We won’t try to track RI compliance in bugzilla, we’ll use the RI issues if needed but otherwise assume the RI is always passing the latest TCK.
Here is a query for unresolved issues in the TCK component (i.e. resolved spec issues requiring TCK updates).
Note: This probably isn’t the ideal workflow for a spec issue, but since we have this coverage gap, it’s worth noting along with the spec issues that are being tracked.
(E.g. better Maven integration, test artifact organization, documentation, other ideas like standalone EE TCK)
See the TCK project on GitHub. These will eventually be described in more detail on the Wiki at the GitHub project. The issues page should also be one starting point.
The effort to rewrite the spec in AsciiDoc is captured in this standards.jsr352.batch-spec repo at the specification subdirectory off of the root level.
Some issues are listed there.
A review is greatly needed/appreciated.