[
https://issues.apache.org/jira/browse/KAFKA-21347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Omnia Ibrahim updated KAFKA-21347:
----------------------------------
Description:
Today, {{release.py}} dispatches on three subcommands only: the default
{{{}stage{}}}, {{{}stage-docs{}}}, and {{{}release-email{}}}. There is no
{{blog}} subcommand. The tooling automates two emails during a release — the RC
vote email and the release announcement email ({{{}release/templates.py{}}}:
{{{}rc_vote_email_text{}}}, {{{}release_announcement_email{}}}) — but the
actual release announcement {*}blog post{*}(e.g.
{{{}kafka-site/content/en/blog/releases/ak-X.Y.Z.md{}}}) along side
`downloads.md` is still written entirely by hand by the release manager for
every release.
In practice, the release manager has to manually:
# Create the blog post file with the correct frontmatter (date, title, slug,
author).
# Re-derive and restate upgrade notes, notable changes, and KIPs in release
plan
# Cross-check version numbers, links, and contributor mentions by hand.
This is repetitive, error-prone (version/date typos, missed KIPs), and slows
down the release-week checklist.
*Proposal:*
Add a command (e.g. {{{}./release.py blog{}}}) that writes a skeleton
{{ak-XYZ.md}} with:
* Hugo front matter populated (title, date, author/RM, any required taxonomy
fields)
* The standard section headings, in the standard order
* Version strings and the release date substituted everywhere they appear
* The contributor acknowledgement list, generated via the existing git helper
in {{{}release/{}}}, deduped and sorted
* A {{<!-- TODO -->}} marker in each body slot the RM must write
* The `downloads.md` section populated with the full set of
artifact/checksum/signature links for the version.
was:
Today, {{release.py}} dispatches on three subcommands only: the default
{{{}stage{}}}, {{{}stage-docs{}}}, and {{{}release-email{}}}. There is no
{{blog}} subcommand. The tooling automates two emails during a release — the RC
vote email and the release announcement email ({{{}release/templates.py{}}}:
{{{}rc_vote_email_text{}}}, {{{}release_announcement_email{}}}) — but the
actual release announcement {*}blog post{*}(e.g.
{{{}kafka-site/content/en/blog/releases/ak-X.Y.Z.md{}}}) along side
`downloads.md` is still written entirely by hand by the release manager for
every release.
In practice, the release manager has to manually:
# Create the blog post file with the correct frontmatter (date, title, slug,
author).
# Re-derive and restate upgrade notes, notable changes, and KIPs in release
plan
# Cross-check version numbers, links, and contributor mentions by hand.
This is repetitive, error-prone (version/date typos, missed KIPs), and slows
down the release-week checklist.
*Proposal:*
Add a command (e.g. {{{}./release.py generate-blog-post{}}}) that writes a
skeleton {{ak-XYZ.md}} with:
* Hugo front matter populated (title, date, author/RM, any required taxonomy
fields)
* The standard section headings, in the standard order
* Version strings and the release date substituted everywhere they appear
* The contributor acknowledgement list, generated via the existing git helper
in {{{}release/{}}}, deduped and sorted
* A {{<!-- TODO -->}} marker in each body slot the RM must write
* The `downloads.md` section populated with the full set of
artifact/checksum/signature links for the version.
> Add release.py blog subcommand to generate initial blog post
> -------------------------------------------------------------
>
> Key: KAFKA-21347
> URL: https://issues.apache.org/jira/browse/KAFKA-21347
> Project: Kafka
> Issue Type: Improvement
> Components: tools
> Reporter: Omnia Ibrahim
> Priority: Major
>
> Today, {{release.py}} dispatches on three subcommands only: the default
> {{{}stage{}}}, {{{}stage-docs{}}}, and {{{}release-email{}}}. There is no
> {{blog}} subcommand. The tooling automates two emails during a release — the
> RC vote email and the release announcement email
> ({{{}release/templates.py{}}}: {{{}rc_vote_email_text{}}},
> {{{}release_announcement_email{}}}) — but the actual release announcement
> {*}blog post{*}(e.g. {{{}kafka-site/content/en/blog/releases/ak-X.Y.Z.md{}}})
> along side `downloads.md` is still written entirely by hand by the release
> manager for every release.
> In practice, the release manager has to manually:
> # Create the blog post file with the correct frontmatter (date, title, slug,
> author).
> # Re-derive and restate upgrade notes, notable changes, and KIPs in release
> plan
> # Cross-check version numbers, links, and contributor mentions by hand.
> This is repetitive, error-prone (version/date typos, missed KIPs), and slows
> down the release-week checklist.
>
> *Proposal:*
> Add a command (e.g. {{{}./release.py blog{}}}) that writes a skeleton
> {{ak-XYZ.md}} with:
> * Hugo front matter populated (title, date, author/RM, any required taxonomy
> fields)
> * The standard section headings, in the standard order
> * Version strings and the release date substituted everywhere they appear
> * The contributor acknowledgement list, generated via the existing git
> helper in {{{}release/{}}}, deduped and sorted
> * A {{<!-- TODO -->}} marker in each body slot the RM must write
> * The `downloads.md` section populated with the full set of
> artifact/checksum/signature links for the version.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
