[VOTE] Pulsar Node.js Client Release 1.8.2 Candidate 1

[Baodi Shi]

Hi everyone,

This is the first release candidate for Apache Pulsar Node.js client,
version 1.8.2.

It fixes the following issues:
https://github.com/apache/pulsar-client-node/pulls?q=is%3Apr+label%3Arelease%2Fv1.8.2+is%3Aclosed


Please download the source files and review this release candidate:
- Download the source package, verify shasum and asc
- Follow the README.md  to build and run the Pulsar
Node.js client.

The release candidate package has been published to the npm registry:

https://www.npmjs.com/package/pulsar-client/v/1.8.2-rc.1

You can install it by `npm i pulsar-client@1.8.2-rc.1
--pulsar_binary_host_mirror=
https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-node/` and
verify the package.

You can refer to this repository to verify tls related features:

   - https://github.com/shibd/pulsar-client-tls-test


The vote will be open for at least 72 hours. It is adopted by majority
approval, with at least 3 PMC affirmative votes.

Source files:
https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-node/pulsar-client-node-1.8.2-rc.1/


Pulsar's KEYS file containing PGP keys we use to sign the release:
https://dist.apache.org/repos/dist/dev/pulsar/KEYS

SHA-512 checksum:

2181fb2ebe22c806b8aaf4d3700c61bd2c6a8d240462bf5f870c16a882d1ca9fc3f164e3c139900145934e68f14f21cbaaeb232157f76f6c92e627dced3e861e
 ./apache-pulsar-client-node-1.8.2.tar.gz

The tag to be voted upon:
v1.8.2-rc.1(769d7cc)
https://github.com/apache/pulsar-client-node/releases/tag/v1.8.2-rc.1

Please review and vote on the release candidate #1 for the version 1.8.2,
as follows:
[ ] +1, Approve the release
[ ] -1, Do not approve the release (please provide specific comments)


Thanks,
Baodi Shi

[Discuss] Add a phase to process pending PRs before code freeze

[Yunze Xu]

Hi community,

I see the code freeze of Pulsar 3.0.0 is coming tomorrow. But I found
the release process still lacks a key step that pending PRs should be
taken carefully of instead of simply delaying them to the next
release.

The following cases were very often seen:
1. A PR has opened for some days and no one reviewed it.
2. A reviewer left some comments and the author disappeared for some time.
3. The author of a PR has addressed the requested changes but the
reviewer has disappeared for some time.

As we know, Apache committers are volunteers and have their own jobs.
So the cases above are all acceptable. However, before a release, I
think the release managers must take the responsibility to handle the
cases above.

IMO, we must address the cases about (at least 1 and 3 are
controllable) one week in advance. If the PR cannot be merged due to
the disappearance of the author, it's okay to delay it to the next
release. But the release managers should address the PRs actively.
They can help review the PRs. Or at least,
- for case 1: they can ping some committers that are familiar with the
scope of the PR to review it.
- for case 2: they can ping the author
- for case 3: they can ping the reviewer

I see Zike noticed the time point of the code freeze last week:
https://lists.apache.org/thread/tczgh4y8lcy2y85652vkctbkcrs40nq4. But
there is no clear process for how to process the pending PRs before
the code freeze.

Thanks,
Yunze

Re: [Discuss] Add a phase to process pending PRs before code freeze

[Yunze Xu]

To be more specific, we can send a discussion thread one week before
the code freeze. Then,
1. The PRs opened after the time point won't be considered to be
included in this release
2. If someone has some pending PRs that are aimed to be included in
this release, it's better to comment in the discussion thread.

For example, [1] aimed to drop the streaming dispatcher in 3.0.0.
However, there was no PR yet. If the PR was opened today and merged
very quickly, there might not be enough time to complete the review
process. We cannot assume a PR won't receive any request change.

[1] https://lists.apache.org/thread/ky2bkzlz93njx3ntnvkpd0l77qzzgcmv

Thanks,
Yunze

On Mon, Apr 10, 2023 at 10:56 AM Yunze Xu  wrote:
>
> Hi community,
>
> I see the code freeze of Pulsar 3.0.0 is coming tomorrow. But I found
> the release process still lacks a key step that pending PRs should be
> taken carefully of instead of simply delaying them to the next
> release.
>
> The following cases were very often seen:
> 1. A PR has opened for some days and no one reviewed it.
> 2. A reviewer left some comments and the author disappeared for some time.
> 3. The author of a PR has addressed the requested changes but the
> reviewer has disappeared for some time.
>
> As we know, Apache committers are volunteers and have their own jobs.
> So the cases above are all acceptable. However, before a release, I
> think the release managers must take the responsibility to handle the
> cases above.
>
> IMO, we must address the cases about (at least 1 and 3 are
> controllable) one week in advance. If the PR cannot be merged due to
> the disappearance of the author, it's okay to delay it to the next
> release. But the release managers should address the PRs actively.
> They can help review the PRs. Or at least,
> - for case 1: they can ping some committers that are familiar with the
> scope of the PR to review it.
> - for case 2: they can ping the author
> - for case 3: they can ping the reviewer
>
> I see Zike noticed the time point of the code freeze last week:
> https://lists.apache.org/thread/tczgh4y8lcy2y85652vkctbkcrs40nq4. But
> there is no clear process for how to process the pending PRs before
> the code freeze.
>
> Thanks,
> Yunze