This guide was generated from real release vote discussions on the Apache Incubator mailing list and reflects practical issues that sometimes arise during podling release reviews.

Who This Guide Is For

This guide is intended for:

  • Podling PPMCs
  • Release managers
  • Incubator mentors
  • IPMC members

It is designed to support practical decision-making when preparing a release candidate, calling a vote, responding to review feedback, and iterating to a successful release.

Unifying Principle

A podling release vote is a public review process. It helps the project demonstrate transparency, responsiveness to feedback, and growing release maturity.

Purpose

This guide summarises a small set of practical review topics that sometimes arise during Incubator release votes.

It was generated from five years of release vote discussions on incubator-general. Many votes are routine and complete without substantive issues. This document focuses on cases where reviewers asked questions or requested changes, so that mentors and podlings can recognise such situations earlier.

It is mentoring guidance based on real Incubator experience, but does not replace ASF policy or legal guidance.

1. LICENSE Completeness

In some votes, reviewers may ask whether a release artifact properly accounts for bundled or embedded third-party material.

This typically arises when:

  • The vote email does not clearly explain what is shipped in the source artifact
  • The relationship between bundled material and external dependencies is unclear
  • The LICENSE file does not obviously reflect what is included

Clear disclosure helps reduce follow-up questions.

2. Bundled Third-Party Material

Bundled third-party content is not inherently a problem, but it must be handled correctly in the release artifact.

The authoritative record of bundled third-party material is the LICENSE file.

Review questions tend to arise when:

  • bundled third-party material appears in the source tree but is not clearly reflected in LICENSE
  • it is unclear whether third-party components are shipped or only referenced as dependencies

A short explanatory paragraph in the vote email can help reviewers navigate the release, but it does not replace the requirement for bundled material to be properly documented in LICENSE, with original headers preserved where applicable.

3. NOTICE Content

NOTICE can attract reviewer attention when its purpose or content is unclear.

Questions may arise when:

  • NOTICE includes large volumes of dependency information
  • boilerplate text is added without a clear requirement
  • the boundary between LICENSE and NOTICE is unclear

Keeping NOTICE minimal and purposeful helps avoid unnecessary review discussion.

4. NOTICE Housekeeping

Reviewers may also comment on minor NOTICE maintenance issues, such as:

  • stale years
  • formatting inconsistencies

These are rarely blockers, but they still consume review time.

5. Use of the Work-in-Progress Disclaimer

The Work-in-Progress disclaimer provides context for incubating releases.

It may be referenced by reviewers when:

  • issues are viewed as correctable
  • the project is still improving its release process

The disclaimer does not replace the need to address substantive issues raised during review.

6. Licensing Questions Are Resolved Through Artifacts

When licensing questions arise, resolution typically focuses on:

  • clarifying what the artifact includes
  • adjusting packaging or included content
  • updating LICENSE or NOTICE
  • preserving third-party headers and provenance

Licensing concerns are resolved through artifact correctness, not disclaimer wording.

7. KEYS and Verification Convenience

Reviewers may raise practical concerns if:

  • the KEYS file is hard to locate
  • links are incorrect

Clear links and simple verification instructions help reduce back-and-forth.

8. Closing the Loop on Review Feedback

Release votes typically converge once:

  • questions are answered clearly on-list
  • requested corrections are made
  • reviewers can verify the updated artifacts

This is a normal iteration, not a failure.

9. What Release Votes Indicate About Incubation

Release votes provide insight into:

  • how well a project understands what it is shipping
  • its ability to respond constructively to public review
  • whether release practices improve over time

These signals are often more important than any single issue raised.

10. Key Takeaways for PPMCs, Mentors, and the IPMC

  • Many release votes are routine and complete without issues
  • When questions arise, they usually relate to clarity rather than intent
  • Bundled third-party content must be accounted for in LICENSE
  • NOTICE should be minimal and purposeful
  • The Work-in-Progress disclaimer provides context, not cover
  • Licensing questions are resolved through artifact accuracy
  • Clear KEYS links and verification steps help reviewers
  • No labels