| Re: [jakarta.ee-spec.committee] Improving the specification process tracking |
I understand the PMC is adding another check regarding openness and dev process. Can the PMC vote in the steering committee ballot convey both approval of the spec process and development process? That would be the meaning of a +1. If one or both fail, then a -1 with a comment(s) indicates the failing.
I'm trying to come up with a location that is the one source of all approvals. If you look at the jaxb PR example that has been expanded to include the PMC and EMO information, It links to the EMO bug so that state can be tracked.I understand the PMC is adding another check regarding openness and dev process. Can the PMC vote in the steering committee ballot convey both approval of the spec process and development process? That would be the meaning of a +1. If one or both fail, then a -1 with a comment(s) indicates the failing._______________________________________________On Thu, Oct 8, 2020 at 2:18 PM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:The PR checklist is not the one source of tracking. As you've stated the EMO creates tracking bugs with the project leads in copy.We automatically copy project leads on the tracking "bugs" that the EMO creates to track various reviews (including release reviews). We also add the committer who initiates the review in copy (usually, this is the committer who submitted the IP Log for review). We selected this mechanism primarily because this allows us to maintain a connection with the project team but also allow others to monitor the progress by adding themselves in CC.As you noted earlier, you can query Bugzilla for these tracking bugs (here's a Bugzilla query) to find all of the ongoing reviews for EE4J projects (we follow a very well defined pattern with the subject line on bugs to make them easier to track).The EMO creates a bug when we get our first hint that a release review is required. Most often, this happens when the project team requests an IP Log review. But we will also create the bug if we notice a project requesting PMC approval or when the project sends a note to EMO requesting that we set them up for a release review.The PMC approval is not a rubber stamp. It has specific meaning in our implementation of the process. We discussed this during the specification committee meeting last week. The role of the PMC is different from that of the specification committee. This will become more apparent as the projects are unleashed to innovate.The short version is that the PMC approval is an acknowledgement from the PMC that they believe that the project is correctly implementing the Eclipse Foundation Development Process, that the project continues to operate within their defined scope and the charter of the top level project, and that they believe that the documentation provided for the release review is sufficient to provide context around the release. The EMO depends on the PMC having a tighter relationship with their projects operating under their purview than is possible for EMO and we use the release review as a last chance opportunity to address outstanding concerns and issues.We use the mailing list for this for a couple of reasons. First, in order to actually send the email, the committer must subscribe to the PMC list, improving the chances that the project team has at least one representative on that list who can represent the interests of the project in future PMC discussion. Second, it gives me some assurances that the PMC are actually paying attention to the projects (not all PMCs are as active as EE4J). Third, the PMC is not just their specification committee representative; since it's unlikely that any one member of the PMC will have familiarity with the comings and goings of every single project, we address the approval request to the entire PMC. Finally, the EMO has limited resources and needs a consistent manner of making all of the above happen for all of our top level projects.Note that the EMO's practice is to accept a single +1 from any PMC member. We purposefully "drag our feet" for a bit after seeing a first +1 to make sure that other PMC members have a chance to object. And yes, this does happen.TL;DR: the PMC approval requirement comes from the EMO; it is not a steering committee decision.WayneOn Tue, Oct 6, 2020 at 3:15 PM Scott Stark <sstark@xxxxxxxxxx> wrote: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._______________________________________________On Tue, Oct 6, 2020 at 8:04 AM Kevin Sutter <sutter@xxxxxxxxxx> wrote: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
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
--_______________________________________________Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
Join us at our virtual event: EclipseCon 2020 - October 20-22
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
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
Join us at our virtual event: EclipseCon 2020 - October 20-22