rdblue commented on code in PR #10806: URL: https://github.com/apache/iceberg/pull/10806#discussion_r1695832403
########## site/docs/how-to-release.md: ########## @@ -76,17 +70,33 @@ For more information, see the Gradle [signing documentation](https://docs.gradle The release should be executed against `https://github.com/apache/iceberg.git` instead of any fork. Set it as remote with name `apache` for release if it is not already set up. -## Creating a release candidate +## Initiating a new release ### Initiate a discussion about the release with the community -This step can be useful to gather ongoing patches that the community thinks should be in the upcoming release. +A new release can be started by raising a thread on the [dev-list](https://lists.apache.org/list.html?d...@iceberg.apache.org): + +```txt +------------------------------------------------------------ +To: d...@iceberg.apache.org +Subject: [DISCUSS] Apache Iceberg Release x.y.z? + +Hello everyone, + +I would like to discuss a new release of Iceberg because of: +``` + +For what goes into which release, please refer to [semantic versioning](contribute.md#semantic-versioning) section on the contributing page. + +Decisions about releases are made by three groups: -The communication can be started via a [DISCUSS] mail on the dev@ channel and the desired tickets can be added to the github milestone of the next release. +* **Release Manager**: Does the work of creating the release, signing it, counting [votes](#voting), announcing the release and so on. Requires the assistance of a committer for some steps. +* **The community**: Performs the discussion of whether it is the right time to create a release and what that release should contain. The community is encouraged to cast non-binding votes on the release. Review Comment: I typically phrase the last part as "everyone is encouraged to test, validate, and vote on the release to help prevent regressions or issues." While only PMC votes are binding, it is incredibly helpful when non-PMC members find and raise issues. I think the only reason that PMC votes are the only "binding" is because PMC members are the ones with the context for judgement calls (like whether a transient test failure should block a release) and the responsibility to check for more than just functionality (like licensing issues). It may be useful to clarify _why_ votes are structured this way, but I would at least recommend giving reasons for everyone to vote. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For additional commands, e-mail: issues-h...@iceberg.apache.org
