> I would suggest that the PMC needs to provide more support to > whoever the RM for a release is. RMs are perhaps the most > valuable committers we have and let’s try not to overburden them > with extra tasks.
+1 - this is especially important if we want to have more frequent releases. I see two concepts here: release notes and changelog. In my opinion, release notes highlight the important new features and bug fixes, while changelogs are a raw list of changes. I think both provide value, but as Jonathan pointed out, the changelog information is already available on GitHub. I propose that we update the PR template so that our GitHub bot can automatically categorize PRs using GitHub labels. Important PRs that should be highlighted in release notes can get a special label. Then, a standard script can generate the release notes (and possibly a changelog) based on PR labels. The release manager would just run the script and commit the output. If someone would like to improve the release notes, they can submit a PR. Also, I think it'd be nice to add a table naming and thanking the contributors for each release. For example, Apache Arrow generates this list using a git command [0]. [0] - https://arrow.apache.org/release/6.0.0.html Thanks, Michael On Thu, Dec 2, 2021 at 9:26 AM Dave Fisher <w...@apache.org> wrote: > > > > > On Dec 2, 2021, at 3:11 AM, Enrico Olivelli <eolive...@gmail.com> wrote: > > > > Hello community, > > > > There is an open discussion on the Pulsar 2.9.0 release notes PR: > > https://github.com/apache/pulsar/pull/12425 > > In reading through the comments there I’m noticing these main themes. > > (1) Wanting to standardize / rewrite PR titles. I don’t think that Developers > from around the globe are going to do that. If this needs to be done then a > volunteer who finds it important to them should review and update the PRs as > they are being created. > > (2) The other issue on consistently marking PR ids and PIPs should be > possible with tooling. > > I would suggest that the PMC needs to provide more support to whoever the RM > for a release is. RMs are perhaps the most valuable committers we have and > let’s try not to overburden them with extra tasks. > > - POI uses automation and accepts whatever title are on the commits. > - For OpenOffice the RM doesn’t create the Release Notes, other members do > into English and then various community members translate them. > > So, let’s not slow the process, but let’s go for eventual consistency. > > Regards, > Dave > > > > > 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 >