Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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?
Should it 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.
 
-Markus
 
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
 
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?


Back to the top