Hi Penghui,
I just started doing something similar for the 2.8.3 release
notes. I think a script is a good place to start for creating release
notes, but I also think the notes will still need to be revised by a
human. I agree with Jonathan's point that a commit log is too detailed
for release notes, even if the commits are perfectly named.
> 1. The title of the PR should be refined during the PR review, before
> merging it.
After reading through some of the commits for the 2.8.3 release, I
agree that we should try to make sure commit names describe the PR's
final effect, even if we don't include every PR name in the release
notes.
> 4. Add the component/ tag before merging the PR
I agree that we can use the `component/` labels to simplify grouping
of PRs. I used the following command to find and open PRs without the
`component/` label:
gh pr list --limit 200 --label "release/2.8.3" --state merged --json
url,labels | jq -c '.[] | select(.labels | any(.name |
startswith("component"))| not) | .url' | xargs -I{} open {}
As you mentioned, ideally, we'd complete classification at merge time,
not at release time. We could probably use our GitHub bot to help
ensure this classification is completed before merging.
Here is my current script to generate a grouped list of PR titles. It
is a work in progress, and it skips PRs without the `component/`
label.
gh pr list --limit 200 --label "release/2.8.3" --state merged --json
labels | jq -c '.[].labels[].name | select(startswith("component"))' |
sort -u | xargs -I{} -t gh pr list --limit 200 --label "release/2.8.3"
--state merged --label {} --json title,number | jq -r '.[] |
[.title,.number] |@tsv'
Thanks,
Michael
On Tue, Mar 8, 2022 at 3:21 AM Yu <li...@apache.org> wrote:
>
> Hi penghui,
>
>
> > 1. The title of the PR should be refined during the PR review, before
> merging it.
> For this item, I'll define the writing rules for PR titles and send them
> out for review.
>
>
> On Tue, Mar 8, 2022 at 10:00 AM PengHui Li <peng...@apache.org> wrote:
>
> > For 2.10.0 release, I'm using `gh` command to generate the release note.
> >
> > For example
> >
> > ```
> > gh pr list -L 1000 --search "is:pr milestone:2.10.0 is:merged
> > -label:release/2.9.1 -label:release/2.9.2 " --json title,number,url | jq -r
> > '.[] | "\(.title) [\(.number)](\(.url))"' | grep -v "website" | grep -v
> > "doc" | grep -v "Documentation"
> > ```
> >
> > I noticed that we need to address couple issues
> >
> > 1. The title of the PR should be refined during the PR review, before
> > merging it.
> > 2. Add the milestone and release/xxx tag(if needed) before merging the PR
> > 3. For merging the PR, the committer need to check the merge information
> > carefully, Github will use the first commit message
> > as the merge commit message, sometime it's not a meaningful message
> > 4. Add the component/ tag before merging the PR
> >
> > So that we can generate the release note automatically according to the
> > component tag.
> >
> > Thanks,
> > Penghui
> >
> > On Wed, Dec 8, 2021 at 9:33 AM Li Li <l...@streamnative.io.invalid> wrote:
> >
> > > +1
> > >
> > >
> > > > On Dec 3, 2021, at 7:49 PM, Anonymitaet _ <anonymita...@hotmail.com>
> > > wrote:
> > > >
> > > > Hi Pulsarers,
> > > >
> > > > Thanks for your suggestions.
> > > >
> > > > I think we need to make consensus on the following issues:
> > > >
> > > > #1
> > > > What should be included in the RN (release note)?
> > > >
> > > > Only include major changes (important features/enhancements/bug fixes)
> > > in list form rather than a raw dump of PRs.
> > > >
> > > > Reason:
> > > >
> > > > - The target audience is Pulsar developers and users, who usually skim
> > > RN to look for features that matter to them, so it is necessary to have
> > > this place for easier search.
> > > >
> > > > - For each release, to help users know the highlights in a quicker way,
> > > usually we write tech blogs [1] to explain more details (e.g. What has
> > > changed?, Why has it changed?, How is the user impacted?, What does the
> > > user need to do now?), so RN can be a "simple list" of what we have
> > > achieved.
> > > >
> > > > - Users can get changelogs on GitHub if they want to know every change
> > > of a release.
> > > >
> > > > #2
> > > > How to create a quality RN efficiently?
> > > >
> > > > If RN is regarded as an afterthought and finished as a last-minute
> > task,
> > > it is likely not written well. Instead of rushing, treating RN as a part
> > of
> > > development reduces release manager's workload and makes communication
> > more
> > > coordinated. Consequently, **the process of the current workflow can be
> > > improved**:
> > > >
> > > > 2.a.
> > > > Create guidelines/standards for writing a qualified PR title (and
> > > description) and git commit message.
> > > > →This really matters for release manager to know the changes and cut a
> > > release.
> > > >
> > > > 2.b.
> > > > Give PR with corresponding labels .
> > > > e.g. `release/note-required`, labels related to PR changes (such as
> > > `component/functions`, `component/java-client`)
> > > > →So that automatic tools knows contain which PR and assign the PR to
> > the
> > > correct chapter in RN.
> > > >
> > > > 2.c.
> > > > Create templates for RN.
> > > >
> > > > 2.d.
> > > > Find tools to generate RN automatically based on qualified PR title, PR
> > > labels, and RN template.
> > > >
> > > > In this case, if each PR information is provided in a consistent and
> > > clear way, RN can be automatically generated in a quick manner. Also it
> > > saves release manager's life.
> > > >
> > > > [1] Tech blog example:
> > > https://pulsar.apache.org/blog/2021/09/23/Apache-Pulsar-2-8-1/
> > > >
> > > >>>>>>>>>>>>>>>
> > > >
> > > > On 2021/12/3, 12:04, "Yunze Xu" <y...@streamnative.io.INVALID> wrote:
> > > >
> > > > First I agree with Jonathan that we should perform some changes with
> > > > the original PR descriptions.
> > > >
> > > > Then, classifying these PRs is also necessary, otherwise the release
> > > notes
> > > > would be meaningless. There are a lot of PRs that should be
> > classfied
> > > in
> > > > Misc part of https://github.com/apache/pulsar/pull/12425 <
> > > https://github.com/apache/pulsar/pull/12425> and I also gave
> > > > some comments in the PR.
> > > >
> > > > IMO, it’s okay to ignore the PRs that only fix some typos or fix
> > some
> > > flaky tests.
> > > > But I found many PRs in Misc part should also be noted.
> > > >
> > > > We should not sacrifice the release quality for a new release like
> > > 2.9.1.
> > > >
> > > >> 2021年12月2日 下午7:11，Enrico Olivelli <eolive...@gmail.com> 写道：
> > > >>
> > > >> Hello community,
> > > >>
> > > >> There is an open discussion on the Pulsar 2.9.0 release notes PR:
> > > >> https://github.com/apache/pulsar/pull/12425
> > > >>
> > > >> I have created the block of release notes by downloading the list of
> > PR
> > > >> using some GitHub API.
> > > >> Then I have manually classified:
> > > >> - News and Noteworthy: cool things in the Release
> > > >> - Breaking Changes: things you MUST know when you upgrade
> > > >> - Java Client, C++ Client, Python Client, Functions/Pulsar IO
> > > >>
> > > >> The goal is to provide useful information for people who want to
> > upgrade
> > > >> Pulsar.
> > > >>
> > > >> My problems are:
> > > >> - PR titles are often badly written, but I don't want to fix all of
> > them
> > > >> (typos, tenses of verbs, formatting)
> > > >> - There are more than 300 PRs, I don't want to classify them
> > manually, I
> > > >> just highlighted the most important from my point of view
> > > >>
> > > >> If for 2.9.0 we still keep a list of PR, then I believe that the
> > current
> > > >> status of the patch is good.
> > > >>
> > > >> If we want to do it another way, then I am now asking if there is
> > > someone
> > > >> who can volunteer in fixing and classifying the list of 300 PRs, it
> > is a
> > > >> huge task.
> > > >>
> > > >> There is already much more work to do to get 2.9.0 completely released
> > > (and
> > > >> also PulsarAdapters) and we have to cut 2.9.1 as soon as possible due
> > > to a
> > > >> bad regression found in 2.9.0.
> > > >>
> > > >> Thanks
> > > >> Enrico
> > > >
> > > >
> > > >
> > >
> > >
> >
