Add "working branches" section to Committer-Conventions

jim-krueger commented 4 months ago

In an effort to allow for accelerated development and prototype work for the proposed release-3.2 effort I’d like to add the following section to our Committer Conventions. I initially sent this as a note in the mailing list and have made a few adjustments.

Please vote and/or add suggestions.

Working Branches

Occasionally there may be a need for the community to collaborate and develop changes for the purposes of prototyping etc. In those cases a “working branch” may be created that will be managed with exceptions to the conventions stated above:

What is a Working Branch?

A working branch is a branch created for accelerated development and prototyping purposes
A branch must receives 3 committer +1 votes (and no -1 votes) before being designated as a working branch.
A working branch does not correspond directly to any documented release plan.
Content in a working branch will need full approval via the Committer Conventions above before being added to the master/release/main branch or any branch corresponding to a documented release plan.

Exceptions to Committer Conventions for Working Branches

(1) There will be no minimum wait time to merge / close PRs.

(2) PRs may be merged / closed following review and approval by at least one committer (other than the submitter themself).

jamezp commented 4 months ago

+1 this makes sense to me.

mkarg commented 4 months ago

+-0: I do not have objections, but I do not actively support any weakening of the committer rules.

jim-krueger commented 4 months ago

I don't see this as a weakening of the committer rules since any and all changes that would be placed in the master/main or any branch corresponding to an active release plan would need to follow the established committer rules. This would only be allowing our group to collaborate quickly on a separate working branch. An advantage being that the entire group will be exposed to the prototyping work being done, rather than having those involved working separately to avoid being held up by the current process.

jansupol commented 4 months ago

+0: I can see the urge for this for 3.2, but for other non-urged branches I feel relaxed about having extra time, especially during the summer vacation time.

jim-krueger commented 4 months ago

I can see the urge for this for 3.2, but for other non-urged branches I feel relaxed about having extra time, especially during the summer vacation time.

@jansupol I've added the following above. Does that possibly change your vote?

A branch must receives 3 committer +1 votes (and no -1 votes) before being designated as a working branch.

Here is an example of why this is needed. PR 1217 changes the spec and therefore (per the current Committer Conventions) it cannot be merged for another week even though it has been approved. This would also apply to any PR that changed any API. This makes prototype collaboration very slow.

jansupol commented 4 months ago

+1 if there is a list of current working branches, possibly in the Readme or on Wiki

jim-krueger commented 4 months ago

if there is a list of current working branches, possibly in the Readme or on Wiki

Good idea. As soon as this passes I will add a list to the wiki and add a link to it in the Committer Conventions.

asoldano commented 4 months ago

+1, this looks ok to me

jim-krueger commented 4 months ago

So for there have been 3 - +1 votes including two committers beyond myself and 1 - 0 votes. If there are no -1 votes by next Tuesday (February 20th) I will add the above to our Committer Conventions. Thanks

jimma commented 4 months ago

+1, this looks good .

spericas commented 4 months ago

+1

jim-krueger commented 4 months ago

I've added the new section to the Committer Conventions.

Closing issue

jakartaee / rest