Wayne Beaton wrote on 8/14/19 12:28 PM:
Greetings Specification Committee
Unless directed otherwise, I will initiate votes for
specifications when I see the pair of pull requests in with
the "final" label. I will check the list periodically, but do
ping me if you think that something appears stalled.
As I initiate ballots, I am labeling issues with "ballot"
and am updating the "Specification Committee Ballot Start
Date" column that I added to the spreadsheet.
I'll create PRs with ballot results as they come to
completion. I propose that, as ballots complete, I label PRs
as "approved". Let me know if you have any concerns with
that practice, or would prefer a different label.
I assume you'll first merge the existing PRs for the approved specs,
then submit and merge PRs (or directly update the repo) to reflect
the ballot results.
Is a separate manual operation required to make this content appear
on the jakarta.ee web site?
Also, you'll need to coordinate with David, who I assume is going to
run the job that signs and publishes the approved TCKs.
The certification requests will also need to be marked accepted. I
assume that will be done by the project lead for the specification
project, once the ballot is approved?
We'll also need to remind the project teams to send email to
tck@xxxxxxxxxxx with a link to the certification request when the
certification request is marked accepted.
There's a lot of steps in this process, involving a lot of
different people. Do we need another checklist for how to approve a
spec?
As I've been starting ballots, I've also been creating
release records on behalf of the corresponding projects;
these release records all indicate September 10 as the
release date. As far as EMO is concerned, no additional
information is required on these release records, but
project team members can add more information if they choose
to do so.
Ideally the project teams were supposed to do this; we added it as
step 9 in our instructions.
But thanks for doing it for us!
I created a "simultaneous release" record and
have been attaching these release records to it. Note that
this works at the Specification Project level, so some
individual specifications (e.g. Jakarta Dependency
Injection) will not appear.
As projects that require a release review come up for
ballot, I'm creating release review tracking bugs (e.g. Bug 550079 for Jakarta CDI);
these bugs will have the project lead(s) in copy and do
include instructions (basically we need to review the IP Log
and get PMC approval). I'll schedule the release reviews to
conclude as early as possible (e.g. on the same day that the
ballots for all of the Specifications that are part of the
Specification Project wrap up).
Sounds good, thanks Wayne!
|
