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.
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.
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).
Wayne
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
