> 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.
+1
Thanks,
Penghui
On Wed, Mar 9, 2022 at 4:06 AM Michael Marshall <mmarsh...@apache.org>
wrote:
> 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
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
>
