For others, there are the development/release branches (Which could have been used for EE11 as well, and the only reason why they are not used I can see is the last 2 week approval period from the release branch to main, correct?)
Actually no. I assume the other development/release branches you are referring to here are “release-4.0” and “release -3.2”. The truth is when we decided to go with a minimal set for Jakarta Rest 4.0, neither of those branches were great candidates. The “release-4.0” branch had a lot of changes to remove @Context injection, and “release-3.2” had a lot of changes to deprecate @Context injection. So we decided to use the master/main branch instead. James Perkins then created a PR to update that branch with changes from the “release-4.0”, “release-3.2”, and “release-3.1.x” to bring it up to speed.
The main branch is not a “working branch” since it will be associated directly with work for the 4.0 release.
And the proposed change discussed in this note is simply intended to allow changes to be fast tracked during time constrained periods of development when the default 2-week delay for each PR is not prudent. I feel that this will not be a problem since time constrained periods of development generally correspond to heightened committer involvement and attention. We can always re-visit this at any time if it appears that problems are resulting or the fast-track process is being abused. On Feb 27, 2024, at 4:57 PM, Jan Supol <jan.supol@xxxxxxxxxx> wrote:
+1 temporarily for EE11.
For others, there are the development/release branches (Which could have been used for EE11 as well, and the only reason why they are not used I can see is the last 2 week approval period from the release branch to main, correct?)
From: rest-dev <rest-dev-bounces@xxxxxxxxxxx> on behalf of Jim Krueger via rest-dev <rest-dev@xxxxxxxxxxx>
Sent: Tuesday, February 27, 2024 3:36 PM
To: Jakarta Rest project developer discussions <rest-dev@xxxxxxxxxxx>
Cc: Jim Krueger <jckofbyron@xxxxxxxxx>
Subject: [External] : [rest-dev] Proposed change to Committer-Conventions In an effort to allow for accelerated development, while still maintaining control over Jakarta Restful Webservices content, I’d like to start discussion over the following change to our Committer-Convenstions ( https://github.com/jakartaee/rest/wiki/Committer-Conventions)
Currently the "Minimum Length of review period before merge / close of PRs and closing of Issues" section states the following:
(1) Minimum two full weeks is default. (2) For non-API, non-spec, non-javadoc changes (e.g., pom, travis, checkstyle, etc), a proposal to fast track the PR is requested at submission time. If a fast tracked PR receives 3 committer +1 votes (and no -1), it can be merged immediately provided at least 1 day has passed since its submission. Rule #1 above makes it impossible to fix API, spec, or javadoc changes in a situation that demands a faster response. I’d therefore like to add the following to this list: (3) For any time-sensitive change, a proposal to fast track the PR is requested at submission time. If a fast tracked PR receives 4 committer +1 votes (and no -1 vote), it can be merged immediately provided at least 1 day has passed since its submission. If a fast tracked PR receives only 2 or 3 +1 votes (and no -1 vote), it can be merged provided at least 4 days have passed since its submission. Thoughts?
|
