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.

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

Conversation

niallkp
Copy link

@niallkp niallkp commented Mar 7, 2025

The following discussions on members@ talked about urgent releases where the voting period was less than the normal 72 hours:

It is difficult to have a consensus on what an exceptional circumstance is. No-one has disagreed with urgent releases for publicly know security issues. However there was agreement from a number of people (and no disagreement) on the following points:

  • Explain why in the vote email
  • give project members as much "heads up" as possible before the vote is called
  • since its not following normal policy it must be reported to the board

I've tried to encapsulate that in a new section in the release policy doc. However I'm not the best wordsmith so please feel free to improve

Copy link
Contributor

@markt-asf markt-asf left a comment

Choose a reason for hiding this comment

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

Looks good to me. Just the one trivial nit with the proposed text.

@@ -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

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

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

@tisonkun tisonkun requested a review from rvs March 8, 2025 02:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants