I agree with you Arjan. I think that the 2-week roadblock to prevent merges is unnecessary. given that changes are not immediately delivered in a release and can easily be reverted if they cause a problem. However, I’m a fairly new Jakarta Rest committer and therefore am not aware of the issues that caused this restriction to be created in the first place.
On Mar 4, 2024, at 7:06 AM, Arjan Tijms <arjan.tijms@xxxxxxxxxxx> wrote:
Hi,
Maybe a more radical approach, but what if we do no rules at all?
We're not little children here, if someone honestly feels a commit is reasonable to be merged right away, merge it. If you're not sure, ask for review and wait before merging. If something was merged and others disagree, do a revert or a follow-up PR.
Thoughts?
Kind regards, Arjan Tijms
+1 for the "pure bug fix" change. -Markus Von: Jim Krueger [mailto:jckofbyron@xxxxxxxxx] Gesendet: Sonntag, 3. März 2024 21:16 An: Markus Karg Cc: Jakarta Rest project developer discussions Betreff: Re: [rest-dev] Proposed change to Committer-Conventions 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. (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.
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. 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. 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? _______________________________________________
rest-dev mailing list
rest-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
|