Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a section on "Expedited Releases" to the Release Policy #457

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
+31 −1
Open

Add a section on "Expedited Releases" to the Release Policy #457

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
5d2df9d
Add a section on "Expedited Releases" to the Release Policy
niallkp Mar 7, 2025
bfad231
Feedback on "Expedited Releases" change from raboof
niallkp Mar 7, 2025
632e13e
Feedback on "Expedited Releases" change from potiuk
niallkp Mar 7, 2025
b764cd0
Feedback on "Expedited Releases" change from sebbASF
niallkp Mar 7, 2025
c1129c2
Feedback on "Expedited Releases" change from markt-asf
niallkp Mar 7, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 31 additions & 1 deletion content/legal/release-policy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,37 @@ requirements of ASF policy on releases as described below, validate all
cryptographic signatures, compile as provided, and test the result on their
own platform.

Release votes SHOULD remain open for at least 72 hours.
Release votes SHOULD remain open for at least 72 hours. See
[RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) for a good definition of
Copy link
Member

@tisonkun tisonkun Mar 7, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm considering mentioning this at the beginning of this page, since we use the keywords throughout the whole page. Or we can leave the whole reference to RFC-2119 to a follow-up since the explained content here already implies that such a "72 hours" SHOULD can be broken in exceptional circumstances.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its a good point and there are other policy docs also using SHOULD, I wondered the same, but just focusing on this issue and the debates it seemed a good idea to have it close to this wording. Lets see if anyone else agrees with you before deciding whether to remove it from this change

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah .. It would be OK to improve the reference in a follow-up also.

Copy link
Member

@justinmclean justinmclean Mar 8, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the top of the page would be better I think

SHOULD, and the next [Expedited Releases](#expedited-releases) section when
considering a reduced voting period.

#### Expedited Releases {#expedited-releases}
As stated above, the normal policy for releases is to allow 72 hours for
release reviews and votes, however the review/voting period for a release
can be reduced in exceptional circumstances.

ASF projects are made up of distributed teams, in multiple time zones and volunteers
with lives and jobs and the rationale behind 72 hours is to try and give all
members of a project the opportunity to take part in the decision to release.

The most obvious example of an exceptional circumstance would be for a fix for a
publicly known or critical, easily exploitable security issue. Everyone will probably have a different definition
of what an exceptional circumstance is, but ultimately it is down to individual
PMCs to decide for their project.

Projects SHOULD give as much notice as possible for an expedited release in
order to give project members a chance to make time to participate in the
decision.

Emails calling for a Release Vote that run for less than 72 hours MUST include
an explanation of why the release is being expedited.

This policy already states that deviations from normal policy MUST be reported to
the Board, but it is worth emphasising this here specifically for release votes
with a reduced voting time. Unless there are pressing reasons to inform the Board
earlier, reporting can be done in the project's next scheduled board report.


### Publication {#publication}

Expand Down