+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 > > >
