| Re: [rest-dev] Proposed change to Committer-Conventions |
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 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? |