> 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
wrote:
> Hi Penghui,
>
> I just
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 wrote:
> For 2.10.0 release, I'm using `gh` command to generate
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" |
+1
> On Dec 3, 2021, at 7:49 PM, Anonymitaet _ 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
Anonymitaet,
Il giorno ven 3 dic 2021 alle ore 12:50 Anonymitaet _ <
anonymita...@hotmail.com> ha scritto:
> 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
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
Hello Enrico:
I am releasing 2.8.2, and I wrote a small tool to help me generate the 2.8.2
release notes, I found that I need several tags to identify:
1) Component, used to identify which type of PR this PR belongs to. I think we
can discuss which components to keep in the future. There are a
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
> There is already a label `release/note-required` that is being used to
> call out PR/issues when compiling the release notes.
+1 I think we should use this label more--it has only been used 12 times [0].
[0] -
https://github.com/apache/pulsar/pulls?q=is%3Apr+label%3Arelease%2Fnote-required+
There is already a label `release/note-required` that is being used to
call out PR/issues when compiling the release notes.
--
Matteo Merli
On Thu, Dec 2, 2021 at 10:07 AM Michael Marshall wrote:
>
> > I would suggest that the PMC needs to provide more support to
> > whoever the RM for a
> 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
> On Dec 2, 2021, at 3:11 AM, Enrico Olivelli 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 /
I don't think a raw dump of PRs is right for release notes even if the
commit messages are perfectly written by God. It's too low level for
almost everyone, and the people who really do want commit-level detail can
just use git, which is a better tool for exploring history than a static
text
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
14 matches
Mail list logo
