| Hi,
It looks good and I like your idea, but my understanding of technical directions PMC should provide is different. It doesn’t mean that what you’ve done is wrong. Possibly it’s just my misunderstanding.
You are talking about a project release plan describing what project is planning to achieve in the next release. This is not technical directions for all EE4J projects, it’s one particular project plan. It will be required by the spec committee for the initial spec review.
My understanding of technical directions is that it’s a set of recommendations for all EE4J projects. It contain general issues projects should address. I also spent some time with Prague folks and we came out with a document published here: https://dmitrykornilov.net/2018/05/18/jakarta-ee-technical-directions/. This is our vision of technical directions. Consider it as a draft. It should be discussed by the community. At the end PMC should review all community comments and create a final technical directions statement.
Thanks, Dmitry
Hi,I know some of this discussion was started
under the "PMC Minutes" subject line, but I thought it would
be better to start a new thread to make it easier to organize...I've been talking with our Java Batch
lead (Scott Kurz) and we came up with some good input, but not necessarily
a draft template... I'll explain. Scott is not a fan of the
current JCP template. For Java EE 8, he was considering an MR for
Java Batch. The JCP template basically requires you to start from
scratch with every new revision. In many cases, you are just copying-and-pasting
from the original to the new template, with only a few sections actually
being updated. He would like to see "common" metadata for
a project to be consistent and only require updates to the specific items
that are affected by a new release.I pointed out the Eclipse Release mechanism.
Some of you are familiar with the MicroProfile project. Here's
an example of a Release definition for MicroProfile 1.3:
https://projects.eclipse.org/projects/technology.microprofile/releases/microprofile-1.3You can enter as much (or as little)
detail required to defined the release content, the release plan, issues
being tracked, etc. Scott liked this type of approach much better.
The overall project information is long-lived (https://projects.eclipse.org/projects/technology.microprofile)
and consistent across releases. But, each release can be further
defined as required by the project.Let's use JAX-RS as a Jakarta example:
https://projects.eclipse.org/projects/ee4j.jaxrsCurrently, there are no additional releases
defined for JAX-RS (other than the creation review, https://projects.eclipse.org/projects/ee4j.jaxrs/governance).
But, the JAX-RS project could create a JAX-RS 2.2 Release definition
(for example) by specifying a proposed release date: https://projects.eclipse.org/node/12849/create-release (All of this information can easily be changed after the fact.) Once
the proposed Release is created, then all of the detail specific to that
release could be filled out (deliverables, compatibility, milestones, issues,
standards, etc). This is all defined in more detail in the handbook:
https://www.eclipse.org/projects/handbook/#releaseIf this is an agreeable process, we
could require the non-Eclipse based projects (ie. CDI, Bean Validation,
Batch) to still have a "holding project" in Eclipse to capture
this type of release information. The main project page could point
off to their real location (Red Hat, Apache, IBM, etc) for the project
artifacts. I'm just trying to point out that we would not require
all Jakarta projects to be an Eclipse project -- just the release tracking
information. This is very similar to the JCP requirements, except lighter
weight.For the Platform, we could aggregate
all of the component release information into a single interface that is
easy to navigate.Just an idea to discuss. We could
re-use existing capabilities within the Eclipse foundation without having
to invent something new. I'm sure this Eclipse Release process isn't
perfect, but with Wayne on the PMC, I'm sure we could get some tweaks done
to satisfy the requirements. :-)Some additional ideas for either the
static or dynamic content...- package prefix (io.jakarta)
- maven coordinates/URL of artifacts
- project dependencies (especially other
ee4j projects -- Wayne's graphing experiment may help here)
- project "health" -- something
along the lines of Apache project status (committers, community growth,
blockers, etc)
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter_______________________________________________ ee4j-pmc mailing list ee4j-pmc@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/ee4j-pmc
|
