Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Improving the specification process tracking

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




Back to the top