[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-spec.committee] Improving the specification process tracking
|
The point of having the EMO/PMC items is that the PR checklist is the one source of tracking when the spec teams can be told that they can release their artifacts. Completing the ballot is not sufficient.
Scott,
Thanks for starting
this work! Hopefully, we can figure out a way to streamline some of these
processes. A few comments...
I don't think
the EMO/PMC Tasks belong in the Spec Review Checklist. These are
steps for the Spec Project Team to perform. The Spec Review Checklist
is supposed to be for our (Spec Committee) reviewing benefit. If
anything, these tasks should become part of the initial template when the
PR is first created. As you mentioned below, if there's an easy way
for us to determine that these steps were performed, then we could add
that to the Spec Review Checklist (or maybe that's your step 13?). But,
let's not mix the Spec Project team activities in our Review Checklist.
Along those lines,
step 11 for updating the API jar file should be moved. Either to
the PR template, or as part of the post-ballot issue that we create against
the Spec Project Team.
Isn't Step 12
about ballot complete already covered by our other defined activities --
adding the post-ballot checklist, adding the "approved" label,
sending out the notes, etc?
In your note below,
you mention that the PMC is already notified of the Specification ballots.
That's not entirely true. Ivar is notified since he's the PMC
rep. But, the PMC is not currently notified of the ballots. We
could probably change that putting the PMC email address in the public
Spec Committee mailing list distribution. I know that right now we
have overlapping participation, but that may not always be the case. I
do agree with the general direction here though... If we have the
PMC voting on the Spec ballot, then do we really need to repeat the PMC
vote for the release record? As long as the release record is verified
as part of our Spec Review Checklist, then maybe we have both bases covered
with a single "vote".
Thanks again!
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From:
Scott
Stark <sstark@xxxxxxxxxx>
To:
Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>,
Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
Date:
10/05/2020
21:00
Subject:
[EXTERNAL]
[jakarta.ee-spec.committee] Improving the specification process
tracking
Sent
by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
Related to the specification committee discussion around streamlining the
specification approval process in order to track when specification artifacts
may be released. There was a lack of aligning the specification committee
ballot with the EMO and PMC approval at a gating factor to notifying the
project team they could release their artifacts.
I have added this in a PR to the current checklist, but when looking to
apply this to one of the existing PRs I'm mentoring, I ended up expanding
this more, and pulling in the links to the PMC and EMO links. Here is the
PR that has the added additional EMO/PMC items:
https://github.com/jakartaee/specifications/pull/230
In going over this and pulling the information together, there does seem
to be some steps that can be done to simplify this. First, since the PMC
is a member of the specification committee and votes on ballots, it seems
like the step of specification project emailing the PMC is redundant because
the PMC is notified of the project when it goes to specification ballot.
PMC approval should be implicit in a +1 vote on the specification ballot.
I would propose that we eliminate the step of the project having to email
the PMC in favor of this approach.
Is there any negative feedback from EF on that?
Second, there does not appear to be a straightforward way to track the
status of the EMO approval status. There is a bug created by the EMO to
track a project release when they are notified of the release, but this
is not accessible from the project release page. Either you have to search
the https://bugs.eclipse.orgsite, or use the issue link that is sent to the project in response to requesting
the EMO to approve the release.
It does appear that one can search for a '[release] ee4j.' match in the
bug database to locate all open issues related to the current release.
There is an issues tab on the ee4j projects pages, but nothing is on that
tab. Would it be possible to add the release tracking issue to that page?
Bottom line, if we could streamline the PMC interaction, and have a way
to track the EMO approval, the updated specification committee checklist
allows for a smoother approval process that tracks all of the requirements
needed to release a specification project's artifacts._______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
