2:45 p.m.
I want to get things started re getting more fine-grained issues created
for the various EE 10 spec migration issues linked to
https://issues.redhat.com/browse/WFLY-15679. In many cases the issues
directly linked to WFLY-15679 are too coarse-grained, because there are a
number of distinct tasks that can be done separately for each, and to have
a realistic sense of where we stand we need to have visibility into how
things stand with those finer-grained pieces
A good recommendation I got from Tom Jenkinson is to add a comment on the
various per-spec issues outlining the various types of detailed issues the
assignee should consider filing, along with instructions as to how to do
so. The following is what I propose adding:
"Please consider creating subtasks of this issue for any of the following
or other similar activities that can be accomplished as discrete pieces of
work toward this JIRA's overall goal. Please add the 'EE10' label to any
such issue.
* Ensuring that the standalone TCK for this spec can be run against a
current build of WildFly Preview, and if possible reporting any issues to
spec's working group before it is finalized.[1]
* Creating a branch for the EE 10 variant in the github repo for the JBoss
fork of the spec, based on the appropriate code at Jakarta.[2]
* Integrating a milestone release of the spec API into WildFly's main
branch.
* Integrating a milestone release of the implementation artifacts into
WildFly's main branch.
* Integrating the final release of the spec API into WildFly's main branch.
* Integrating final releases of the implementation artifacts
Reminder: WildFly 27 is feature-boxed, so integrating non-final
dependencies into main is not just ok, it is encouraged. Doing so lets us
identify issues early.
We'll be using these finer-grained issues to better track progress on
https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=14333&view...
and elsewhere."
Note that I don't include passing standalone or parts of the platform TCK
here, because it's not clear to me that that kind of thing can be cleanly
decomposed into discrete pieces of work. We know we need to pass the TCKs.
Note also that this message and the related issues are focused on WildFly
Preview. Our ultimate goal is to convert the standard WildFly code to EE
10, ideally as soon as possible. But to do that we'll need to complete the
work of getting native jakarta.* namespace variants of all our components.
That work can proceed in parallel with our work on EE 10 if we continue to
do it in WFP for now.
[1] I'd only add this to issues where a standalone TCK exists.
[2] I'd only add this to issues where we are using a fork of the EE 9.1
spec API code in WildFly Preview.
Best regards,
Brian