| Markus, I can see that your opinion is set on this matter, which means you are unlikely to change your veto vote. So I guess we’ll just have to agree to disagree on this topic and move on.
Unless others disagree with your suggested “pure bug fixes” update to (2) of the Committer-Conventions, I think that would be a good improvement.
Proposed change: (2) For non-API, non-spec, non-javadoc changes (e.g., pom, travis, checkstyle, etc), and any pure bug fix, 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.
On Mar 3, 2024, at 9:44 AM, Markus Karg <markus@xxxxxxxxxxxxxxx> wrote:
Jim, you wrote "There simply **has** to be a way to streamline the process when necessary. ". After being in the JAX-RS EG since 2007ish, I cannot see "has" as the appropriate term here. The two weeks delay worked fine for us in the past, so we should not make the current extraordinary situation the justification to change a default / rule that worked for us since years. All committers shall have enough time to review all spec and api changes. Often we are on PTO, bound in other projects, or on business travel. Reducing the delay is counterproductive, as it leads to belated changes of already merged code, hence clutters git history and confuses people. We all want to produce the best possible solution, which needs time to review calmly -- which is impossible with full-day other projects or on travel. According to the EF rules the spec lead's voice has no higher priority than that of any other committers. -Markus Von: Jim Krueger [mailto:jckofbyron@xxxxxxxxx]
Gesendet: Sonntag, 3. März 2024 13:56
An: Markus Karg
Cc: Jakarta Rest project developer discussions
Betreff: Re: [rest-dev] Proposed change to Committer-Conventions We can agree that pure bug fixes can be fast-tracked. Adding that to (2) is appropriate. I also agree that changes to the api’s, spec, or javadoc should not be made “hastily”. However, IMHO a blanket 2-week delay on all non-bug changes is too arbitrary. There simply has to be a way to streamline the process when necessary. All that should be necessary is for the group to agree on what the criteria should be? - The current 2 week delay on everything?
- Approval by a certain number of committers (3.4.5….)?
- Approval by a certain number of committers plus the spec lead?
- Other suggestions?
Ultimately it isn’t as though changes to the spec, api’s, or javadoc are automatically released in a version. Objections to changes and requests to revert changes can always be made after a merge.
On Mar 2, 2024, at 6:53 AM, Markus Karg <markus@xxxxxxxxxxxxxxx> wrote: Too complex, too much whens-thens. IMHO it should be sufficient to say that pure bug fixes can be fast-tacked under the terms of (2). Whether or not something it time-sensitive should not be considered. We as a spec project never have time-sensitive changes. If a change comes later, it comes later. It's done when it's done, and I am explicitly -1 to do things hastily. Von: rest-dev [mailto:rest-dev-bounces@xxxxxxxxxxx] Im Auftrag von Jim Krueger via rest-dev
Gesendet: Dienstag, 27. Februar 2024 15:36
An: Jakarta Rest project developer discussions
Cc: Jim Krueger
Betreff: [rest-dev] Proposed change to 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?
|
