[DISCUSS] Remove new method in AuthorizationProvider Interface

[Michael Marshall]

Hello,

I recently came across PR 12600 [0]. It was merged in November and
cherry picked to branch-2.8 and branch-2.9. It fixes a bug and adds a
public method to the AuthorizationProvider interface. I am pretty sure
the method is an unnecessary expansion of the interface and it could
lead to a breaking change in 2.8 or 2.9, so I think we should remove
it before including it in any releases. I opened a PR to remove the
method [1]. I describe the risk in more detail there. Please take a
look.

[0] - https://github.com/apache/pulsar/pull/12600
[1] - https://github.com/apache/pulsar/pull/13133

Thanks,
Michael

Re: Missing check on .jar files committed to the source repo

[Dave Fisher]

> On Dec 3, 2021, at 11:45 AM, Michael Marshall  wrote:
> 
>> Automated checks are useful because we are human and we usually miss to
>> validate this kind of boring stuff.
> 
> +1 I think it sounds appropriate to add an automated check. If a use
> case arises where we need to add compiled files, we'll also need a way
> to bypass/override this check.

For example, have a look at why grade wrapper jars cannot be included - 
https://issues.apache.org/jira/browse/LEGAL-570

Regards,
Dave

> 
> Michael
> 
> On Fri, Dec 3, 2021 at 7:10 AM Enrico Olivelli  wrote:
>> 
>> Il giorno ven 3 dic 2021 alle ore 10:36 ZhangJian He 
>> ha scritto:
>> 
>>> I agree. I mean that the situation can be easily judged during the review
>>> process. So I think the automated check sames not so valuable.
>>> If you prefer, I have no objection.
>>> 
>> 
>> Automated checks are useful because we are human and we usually miss to
>> validate this kind of boring stuff.
>> It is very like LICENSE headers, NOTICE files, checkstyle
>> :-)
>> 
>> Enrico
>> 
>>> 
>>> 
>>> Thanks
>>> ZhangJian He
>>> 
>>> Enrico Olivelli  于2021年12月3日周五 17:22写道：
>>> 
 Il giorno ven 3 dic 2021 alle ore 10:20 ZhangJian He >>> 
 ha scritto:
 
> Gradle has `gradle-wrapper.jar` too. I think we don't need an automated
> check, the reviewers can find if it's reasonable.
> 
 
 For some files there are specific acceptance rules.
 But we cannot commit other files that are not needed.
 
 
 Enrico
 
 
> 
> Enrico Olivelli  于2021年11月10日周三 16:47写道：
> 
>> ping
>> 
>> 
>> Il giorno ven 5 nov 2021 alle ore 09:23 Enrico Olivelli <
>> eolive...@gmail.com>
>> ha scritto:
>> 
>>> Hello,
>>> This patch [1] contains a .jar file that must not be committed to
>>> the
>>> source repository.
>>> We generally cannot commit binary files to the source repo, as it
 won't
>> be
>>> "open source" anymore.
>>> 
>>> When we are permitted to commit binary/compiled code, there must
>>> be a
>> very
>>> good reason and it must be approved explicitly and noted somewhere
>> (NOTICE
>>> file?)
>>> 
>>> My point here is that we are missing some automated check to
>>> prevent
> such
>>> accidental commits.
>>> I believe that we have to add a check to be run at every PR
 validation
>> and
>>> during the release process that our source distribution does not
> contain
>>> compiled code.
>>> 
>>> Thoughts ?
>>> 
>>> Enrico
>>> 
>>> [1] https://github.com/apache/pulsar/pull/12535
>>> 
>>> 
>> 
> 
 
>>> 

Re: Missing check on .jar files committed to the source repo

[Michael Marshall]

> Automated checks are useful because we are human and we usually miss to
> validate this kind of boring stuff.

+1 I think it sounds appropriate to add an automated check. If a use
case arises where we need to add compiled files, we'll also need a way
to bypass/override this check.

Michael

On Fri, Dec 3, 2021 at 7:10 AM Enrico Olivelli  wrote:
>
> Il giorno ven 3 dic 2021 alle ore 10:36 ZhangJian He 
> ha scritto:
>
> > I agree. I mean that the situation can be easily judged during the review
> > process. So I think the automated check sames not so valuable.
> > If you prefer, I have no objection.
> >
>
> Automated checks are useful because we are human and we usually miss to
> validate this kind of boring stuff.
> It is very like LICENSE headers, NOTICE files, checkstyle
> :-)
>
> Enrico
>
> >
> >
> > Thanks
> > ZhangJian He
> >
> > Enrico Olivelli  于2021年12月3日周五 17:22写道：
> >
> > > Il giorno ven 3 dic 2021 alle ore 10:20 ZhangJian He  > >
> > > ha scritto:
> > >
> > > > Gradle has `gradle-wrapper.jar` too. I think we don't need an automated
> > > > check, the reviewers can find if it's reasonable.
> > > >
> > >
> > > For some files there are specific acceptance rules.
> > > But we cannot commit other files that are not needed.
> > >
> > >
> > > Enrico
> > >
> > >
> > > >
> > > > Enrico Olivelli  于2021年11月10日周三 16:47写道：
> > > >
> > > > > ping
> > > > >
> > > > >
> > > > > Il giorno ven 5 nov 2021 alle ore 09:23 Enrico Olivelli <
> > > > > eolive...@gmail.com>
> > > > > ha scritto:
> > > > >
> > > > > > Hello,
> > > > > > This patch [1] contains a .jar file that must not be committed to
> > the
> > > > > > source repository.
> > > > > > We generally cannot commit binary files to the source repo, as it
> > > won't
> > > > > be
> > > > > > "open source" anymore.
> > > > > >
> > > > > > When we are permitted to commit binary/compiled code, there must
> > be a
> > > > > very
> > > > > > good reason and it must be approved explicitly and noted somewhere
> > > > > (NOTICE
> > > > > > file?)
> > > > > >
> > > > > > My point here is that we are missing some automated check to
> > prevent
> > > > such
> > > > > > accidental commits.
> > > > > > I believe that we have to add a check to be run at every PR
> > > validation
> > > > > and
> > > > > > during the release process that our source distribution does not
> > > > contain
> > > > > > compiled code.
> > > > > >
> > > > > > Thoughts ?
> > > > > >
> > > > > > Enrico
> > > > > >
> > > > > > [1] https://github.com/apache/pulsar/pull/12535
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >

Re: [DISCUSS] How to handle stale PRs

[Jonathan Ellis]

Agreed.

I don't think I understand tison's objection to closing very stale PRs
automatically -- if it's gone that long without attention the situation
isn't likely to change.  And the submitter can always reopen it if it's
still relevant.

On Fri, Dec 3, 2021 at 1:17 PM Dave Fisher  wrote:

> I think that any Pulsar committer ought to close any PR that is more than
> one year old. That would clear about 75 from the backlog. The OP should be
> informed and if they are still interested then they can discuss it here.
>
> So when a stale PR is closed we should suggest that the OP subscribe to
> and email dev@pulsar.apache.org to discuss the PR.
>
> All the Best,
> Dave
> .
> > On Dec 3, 2021, at 9:17 AM, tison  wrote:
> >
> > From my experience, any process won't work. The only way is to inspire
> more
> > reviewers act on PRs.
> >
> > Instead of talking about how to do it, reviewing one PR now can help the
> > case.
> > Also, it's reasonable to close inactive PR if there is a successor. But
> do
> > not let
> > a bot do it, which will create many corner (bad) cases.
> >
> > Best,
> > tison.
> >
> >
> > Michael Marshall  于2021年12月4日周六 00:57写道：
> >
> >> Hi Pulsar Community,
> >>
> >> I am excited to start contributing as a committer! I have a question
> >> about our process for closing stale PRs.
> >>
> >> We have ~300 open PRs right now. Do we have any guidelines on closing
> >> stale PRs? Of course we don't want to ignore important bug fixes, but
> >> we also don't want to clutter our repo with open PRs that won't get
> merged.
> >>
> >> For example, I reviewed this PR [0] about 3 months ago. The
> >> contributor has not yet responded to my feedback and it doesn't seem
> >> to fix an actual bug, so I think it is a candidate for closure. Here
> >> is another example [1]. I closed this one because it had merge
> >> conflicts with a commit that fixed the same underlying issue.
> >>
> >> Note that our committer guidelines [2] do not provide guidance on this
> >> subject.
> >>
> >> [0] - https://github.com/apache/pulsar/pull/11237
> >> [1] - https://github.com/apache/pulsar/pull/11162
> >> [2] - https://github.com/apache/pulsar/wiki/Committer-Guide
> >>
> >> Thanks,
> >> Michael
> >>
>
>

-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

Re: [DISCUSS] How to handle stale PRs

[Dave Fisher]

I think that any Pulsar committer ought to close any PR that is more than one 
year old. That would clear about 75 from the backlog. The OP should be informed 
and if they are still interested then they can discuss it here.

So when a stale PR is closed we should suggest that the OP subscribe to and 
email dev@pulsar.apache.org to discuss the PR.

All the Best,
Dave
.
> On Dec 3, 2021, at 9:17 AM, tison  wrote:
> 
> From my experience, any process won't work. The only way is to inspire more
> reviewers act on PRs.
> 
> Instead of talking about how to do it, reviewing one PR now can help the
> case.
> Also, it's reasonable to close inactive PR if there is a successor. But do
> not let
> a bot do it, which will create many corner (bad) cases.
> 
> Best,
> tison.
> 
> 
> Michael Marshall  于2021年12月4日周六 00:57写道：
> 
>> Hi Pulsar Community,
>> 
>> I am excited to start contributing as a committer! I have a question
>> about our process for closing stale PRs.
>> 
>> We have ~300 open PRs right now. Do we have any guidelines on closing
>> stale PRs? Of course we don't want to ignore important bug fixes, but
>> we also don't want to clutter our repo with open PRs that won't get merged.
>> 
>> For example, I reviewed this PR [0] about 3 months ago. The
>> contributor has not yet responded to my feedback and it doesn't seem
>> to fix an actual bug, so I think it is a candidate for closure. Here
>> is another example [1]. I closed this one because it had merge
>> conflicts with a commit that fixed the same underlying issue.
>> 
>> Note that our committer guidelines [2] do not provide guidance on this
>> subject.
>> 
>> [0] - https://github.com/apache/pulsar/pull/11237
>> [1] - https://github.com/apache/pulsar/pull/11162
>> [2] - https://github.com/apache/pulsar/wiki/Committer-Guide
>> 
>> Thanks,
>> Michael
>> 

Re: [DISCUSS] How to handle stale PRs

[tison]

>From my experience, any process won't work. The only way is to inspire more
reviewers act on PRs.

Instead of talking about how to do it, reviewing one PR now can help the
case.
Also, it's reasonable to close inactive PR if there is a successor. But do
not let
a bot do it, which will create many corner (bad) cases.

Best,
tison.


Michael Marshall  于2021年12月4日周六 00:57写道：

> Hi Pulsar Community,
>
> I am excited to start contributing as a committer! I have a question
> about our process for closing stale PRs.
>
> We have ~300 open PRs right now. Do we have any guidelines on closing
> stale PRs? Of course we don't want to ignore important bug fixes, but
> we also don't want to clutter our repo with open PRs that won't get merged.
>
> For example, I reviewed this PR [0] about 3 months ago. The
> contributor has not yet responded to my feedback and it doesn't seem
> to fix an actual bug, so I think it is a candidate for closure. Here
> is another example [1]. I closed this one because it had merge
> conflicts with a commit that fixed the same underlying issue.
>
> Note that our committer guidelines [2] do not provide guidance on this
> subject.
>
> [0] - https://github.com/apache/pulsar/pull/11237
> [1] - https://github.com/apache/pulsar/pull/11162
> [2] - https://github.com/apache/pulsar/wiki/Committer-Guide
>
> Thanks,
> Michael
>

Re: New committer: Michael Marshal

[Michael Marshall]

Thank you, everyone! I am very excited to contribute in a new way to
our great project!

- Michael

On Fri, Dec 3, 2021 at 10:47 AM Aaron Williams
 wrote:
>
> Congratulations Michael! Thank you for all of your hard work.
>
> On Fri, Dec 3, 2021 at 7:54 AM Lari Hotari  wrote:
>
> > Woot! Congrats Michael!
> >
> > On Fri, Dec 3, 2021 at 9:32 AM Enrico Olivelli 
> > wrote:
> >
> > > The Project Management Committee (PMC) for Apache  Pulsar
> > > has invited Michael Marshal to become a committer and we are pleased to
> > > announce that he has accepted.
> > >
> > > Michael contributed a lot of interesting additions to the project and he
> > is
> > > very active in the community.
> > >
> > > Being a committer enables easier contribution to the
> > > project since there is no need to go via the patch
> > > submission process. This should enable better productivity.
> > >
> > > Congrats Micheal !
> > >
> > >
> > > Enrico Olivelli
> > >
> >

[DISCUSS] How to handle stale PRs

[Michael Marshall]

Hi Pulsar Community,

I am excited to start contributing as a committer! I have a question
about our process for closing stale PRs.

We have ~300 open PRs right now. Do we have any guidelines on closing
stale PRs? Of course we don't want to ignore important bug fixes, but
we also don't want to clutter our repo with open PRs that won't get merged.

For example, I reviewed this PR [0] about 3 months ago. The
contributor has not yet responded to my feedback and it doesn't seem
to fix an actual bug, so I think it is a candidate for closure. Here
is another example [1]. I closed this one because it had merge
conflicts with a commit that fixed the same underlying issue.

Note that our committer guidelines [2] do not provide guidance on this subject.

[0] - https://github.com/apache/pulsar/pull/11237
[1] - https://github.com/apache/pulsar/pull/11162
[2] - https://github.com/apache/pulsar/wiki/Committer-Guide

Thanks,
Michael

Re: New committer: Michael Marshal

[Aaron Williams]

Congratulations Michael! Thank you for all of your hard work.

On Fri, Dec 3, 2021 at 7:54 AM Lari Hotari  wrote:

> Woot! Congrats Michael!
>
> On Fri, Dec 3, 2021 at 9:32 AM Enrico Olivelli 
> wrote:
>
> > The Project Management Committee (PMC) for Apache  Pulsar
> > has invited Michael Marshal to become a committer and we are pleased to
> > announce that he has accepted.
> >
> > Michael contributed a lot of interesting additions to the project and he
> is
> > very active in the community.
> >
> > Being a committer enables easier contribution to the
> > project since there is no need to go via the patch
> > submission process. This should enable better productivity.
> >
> > Congrats Micheal !
> >
> >
> > Enrico Olivelli
> >
>

Re: New committer: Michael Marshal

[Lari Hotari]

Woot! Congrats Michael!

On Fri, Dec 3, 2021 at 9:32 AM Enrico Olivelli  wrote:

> The Project Management Committee (PMC) for Apache  Pulsar
> has invited Michael Marshal to become a committer and we are pleased to
> announce that he has accepted.
>
> Michael contributed a lot of interesting additions to the project and he is
> very active in the community.
>
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
>
> Congrats Micheal !
>
>
> Enrico Olivelli
>

Re: Missing check on .jar files committed to the source repo

[Enrico Olivelli]

Il giorno ven 3 dic 2021 alle ore 10:36 ZhangJian He 
ha scritto:

> I agree. I mean that the situation can be easily judged during the review
> process. So I think the automated check sames not so valuable.
> If you prefer, I have no objection.
>

Automated checks are useful because we are human and we usually miss to
validate this kind of boring stuff.
It is very like LICENSE headers, NOTICE files, checkstyle
:-)

Enrico

>
>
> Thanks
> ZhangJian He
>
> Enrico Olivelli  于2021年12月3日周五 17:22写道：
>
> > Il giorno ven 3 dic 2021 alle ore 10:20 ZhangJian He  >
> > ha scritto:
> >
> > > Gradle has `gradle-wrapper.jar` too. I think we don't need an automated
> > > check, the reviewers can find if it's reasonable.
> > >
> >
> > For some files there are specific acceptance rules.
> > But we cannot commit other files that are not needed.
> >
> >
> > Enrico
> >
> >
> > >
> > > Enrico Olivelli  于2021年11月10日周三 16:47写道：
> > >
> > > > ping
> > > >
> > > >
> > > > Il giorno ven 5 nov 2021 alle ore 09:23 Enrico Olivelli <
> > > > eolive...@gmail.com>
> > > > ha scritto:
> > > >
> > > > > Hello,
> > > > > This patch [1] contains a .jar file that must not be committed to
> the
> > > > > source repository.
> > > > > We generally cannot commit binary files to the source repo, as it
> > won't
> > > > be
> > > > > "open source" anymore.
> > > > >
> > > > > When we are permitted to commit binary/compiled code, there must
> be a
> > > > very
> > > > > good reason and it must be approved explicitly and noted somewhere
> > > > (NOTICE
> > > > > file?)
> > > > >
> > > > > My point here is that we are missing some automated check to
> prevent
> > > such
> > > > > accidental commits.
> > > > > I believe that we have to add a check to be run at every PR
> > validation
> > > > and
> > > > > during the release process that our source distribution does not
> > > contain
> > > > > compiled code.
> > > > >
> > > > > Thoughts ?
> > > > >
> > > > > Enrico
> > > > >
> > > > > [1] https://github.com/apache/pulsar/pull/12535
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Creating Good Release notes

[Enrico Olivelli]

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 major changes (important features/enhancements/bug fixes) in
> list form rather than a raw dump of PRs.


+1


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

+1

>
> 2.c.
> Create templates for RN.
>

+1

>
> 2.d.
> Find tools to generate RN automatically based on qualified PR title, PR
> labels, and RN template.
>

+1

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


I agree on all the points.

Given that 2.9.0 is out of the door, I will give a last bump to the release
notes PR.
we can improve them later if someone has time to spend on it

Being RM is already a huge task and we cannot require people, that are all
volunteers, to
spend so much time to get all the pieces together.


Enrico


>
> [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"  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  写道：
> >
> > 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
>
>
>
>

Welcome Dave Duggins to Pulsar community!

[Anonymitaet _]

Hi Pulsarerers,

Today is a great plus one news day. Our community is growing since Dave Duggins 
joins us!

Dave is a senior technical writer with a lot of crazy skill sets. He will work 
on the redesign work (information architecture) for Pulsar.

In his spare time, Dave nerds out on Star Wars, Marvel movies, anime and 
horror, sci-fi, and fantasy in general.

I appreciate you joining me in providing a warm welcome for Dave!

With excitement,
Anonymitaet

Re: New committer: Michael Marshal

[Anonymitaet _]

Congrats Micheal! 

And thanks for your continuous doc contribution! :-D

On 2021/12/3, 19:22, "Jack Vanlightly"  wrote:

Congratulations Michael, great findings recently!

On Fri, Dec 3, 2021 at 11:49 AM Aloys Zhang  wrote:

> [ External sender. Exercise caution. ]
>
> Congrats Micheal !
>
> Lan Liang  于2021年12月3日周五 18:47写道：
>
> > Congrats :)
> >
> >
> >
> >
> >
> >
> >
> > Best Regards,
> > Lan Liang
> > On 12/3/2021 18:45，Haiting Jiang wrote：
> > Congrats!
> >
> > Haiting Jiang
> >
> > On 2021/12/03 07:32:00 Enrico Olivelli wrote:
> > The Project Management Committee (PMC) for Apache  Pulsar
> > has invited Michael Marshal to become a committer and we are pleased to
> > announce that he has accepted.
> >
> > Michael contributed a lot of interesting additions to the project and he
> is
> > very active in the community.
> >
> > Being a committer enables easier contribution to the
> > project since there is no need to go via the patch
> > submission process. This should enable better productivity.
> >
> > Congrats Micheal !
> >
> >
> > Enrico Olivelli
> >
> >
>
> --
> Best,
> Aloys.
>

Re: Creating Good Release notes

[Anonymitaet _]

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"  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 
 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  写道：
> 
> 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

Re: New committer: Michael Marshal

[Jack Vanlightly]

Congratulations Michael, great findings recently!

On Fri, Dec 3, 2021 at 11:49 AM Aloys Zhang  wrote:

> [ External sender. Exercise caution. ]
>
> Congrats Micheal !
>
> Lan Liang  于2021年12月3日周五 18:47写道：
>
> > Congrats :)
> >
> >
> >
> >
> >
> >
> >
> > Best Regards,
> > Lan Liang
> > On 12/3/2021 18:45，Haiting Jiang wrote：
> > Congrats!
> >
> > Haiting Jiang
> >
> > On 2021/12/03 07:32:00 Enrico Olivelli wrote:
> > The Project Management Committee (PMC) for Apache  Pulsar
> > has invited Michael Marshal to become a committer and we are pleased to
> > announce that he has accepted.
> >
> > Michael contributed a lot of interesting additions to the project and he
> is
> > very active in the community.
> >
> > Being a committer enables easier contribution to the
> > project since there is no need to go via the patch
> > submission process. This should enable better productivity.
> >
> > Congrats Micheal !
> >
> >
> > Enrico Olivelli
> >
> >
>
> --
> Best,
> Aloys.
>

Re: New committer: Michael Marshal

[Aloys Zhang]

Congrats Micheal !

Lan Liang  于2021年12月3日周五 18:47写道：

> Congrats :)
>
>
>
>
>
>
>
> Best Regards,
> Lan Liang
> On 12/3/2021 18:45，Haiting Jiang wrote：
> Congrats!
>
> Haiting Jiang
>
> On 2021/12/03 07:32:00 Enrico Olivelli wrote:
> The Project Management Committee (PMC) for Apache  Pulsar
> has invited Michael Marshal to become a committer and we are pleased to
> announce that he has accepted.
>
> Michael contributed a lot of interesting additions to the project and he is
> very active in the community.
>
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
>
> Congrats Micheal !
>
>
> Enrico Olivelli
>
>

-- 
Best,
Aloys.

Re: New committer: Michael Marshal

[Lan Liang]

Congrats :)







Best Regards,
Lan Liang
On 12/3/2021 18:45，Haiting Jiang wrote：
Congrats!

Haiting Jiang

On 2021/12/03 07:32:00 Enrico Olivelli wrote:
The Project Management Committee (PMC) for Apache  Pulsar
has invited Michael Marshal to become a committer and we are pleased to
announce that he has accepted.

Michael contributed a lot of interesting additions to the project and he is
very active in the community.

Being a committer enables easier contribution to the
project since there is no need to go via the patch
submission process. This should enable better productivity.

Congrats Micheal !


Enrico Olivelli

Re: New committer: Michael Marshal

[Haiting Jiang]

Congrats!

Haiting Jiang

On 2021/12/03 07:32:00 Enrico Olivelli wrote:
> The Project Management Committee (PMC) for Apache  Pulsar
> has invited Michael Marshal to become a committer and we are pleased to
> announce that he has accepted.
> 
> Michael contributed a lot of interesting additions to the project and he is
> very active in the community.
> 
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
> 
> Congrats Micheal !
> 
> 
> Enrico Olivelli
> 

RE: New committer: Michael Marshal

[Ruguo Yu]

Congrats Micheal!

Ruguo Yu

On 2021/12/03 07:32:00 Enrico Olivelli wrote:

> The Project Management Committee (PMC) for Apache  Pulsar

> has invited Michael Marshal to become a committer and we are pleased to

> announce that he has accepted.

> 

> Michael contributed a lot of interesting additions to the project and he is

> very active in the community.

> 

> Being a committer enables easier contribution to the

> project since there is no need to go via the patch

> submission process. This should enable better productivity.

> 

> Congrats Micheal !

> 

> 

> Enrico Olivelli

> 

Re: New committer: Michael Marshal

[Zhengxin Cai]

Congrats Micheal!

tom lee  于2021年12月3日周五 17:32写道：

> Congrats Michael!
>
> Christophe Bornet  于2021年12月3日周五 17:22写道：
>
> > Awesome ! Congrats Michael !
> >
> > Le ven. 3 déc. 2021 à 08:32, Enrico Olivelli  a
> > écrit :
> >
> > > The Project Management Committee (PMC) for Apache  Pulsar
> > > has invited Michael Marshal to become a committer and we are pleased to
> > > announce that he has accepted.
> > >
> > > Michael contributed a lot of interesting additions to the project and
> he
> > is
> > > very active in the community.
> > >
> > > Being a committer enables easier contribution to the
> > > project since there is no need to go via the patch
> > > submission process. This should enable better productivity.
> > >
> > > Congrats Micheal !
> > >
> > >
> > > Enrico Olivelli
> > >
> >
>

Re: Creating Good Release notes

[Lin Lin]

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 lot of 
components now
2) cherry-picked/branch-2.8 and release/2.8.2, `release/2.8.2` is used to 
identify whether the current release, `cherry-picked/branch-2.8` is used to 
identify whether I need to generate documentation for this PR

Lin Lin

On 2021/12/02 11:11:43 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
> 
> 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
> 

Re: Missing check on .jar files committed to the source repo

[ZhangJian He]

I agree. I mean that the situation can be easily judged during the review
process. So I think the automated check sames not so valuable.
If you prefer, I have no objection.


Thanks
ZhangJian He

Enrico Olivelli  于2021年12月3日周五 17:22写道：

> Il giorno ven 3 dic 2021 alle ore 10:20 ZhangJian He 
> ha scritto:
>
> > Gradle has `gradle-wrapper.jar` too. I think we don't need an automated
> > check, the reviewers can find if it's reasonable.
> >
>
> For some files there are specific acceptance rules.
> But we cannot commit other files that are not needed.
>
>
> Enrico
>
>
> >
> > Enrico Olivelli  于2021年11月10日周三 16:47写道：
> >
> > > ping
> > >
> > >
> > > Il giorno ven 5 nov 2021 alle ore 09:23 Enrico Olivelli <
> > > eolive...@gmail.com>
> > > ha scritto:
> > >
> > > > Hello,
> > > > This patch [1] contains a .jar file that must not be committed to the
> > > > source repository.
> > > > We generally cannot commit binary files to the source repo, as it
> won't
> > > be
> > > > "open source" anymore.
> > > >
> > > > When we are permitted to commit binary/compiled code, there must be a
> > > very
> > > > good reason and it must be approved explicitly and noted somewhere
> > > (NOTICE
> > > > file?)
> > > >
> > > > My point here is that we are missing some automated check to prevent
> > such
> > > > accidental commits.
> > > > I believe that we have to add a check to be run at every PR
> validation
> > > and
> > > > during the release process that our source distribution does not
> > contain
> > > > compiled code.
> > > >
> > > > Thoughts ?
> > > >
> > > > Enrico
> > > >
> > > > [1] https://github.com/apache/pulsar/pull/12535
> > > >
> > > >
> > >
> >
>

Re: New committer: Michael Marshal

[tom lee]

Congrats Michael!

Christophe Bornet  于2021年12月3日周五 17:22写道：

> Awesome ! Congrats Michael !
>
> Le ven. 3 déc. 2021 à 08:32, Enrico Olivelli  a
> écrit :
>
> > The Project Management Committee (PMC) for Apache  Pulsar
> > has invited Michael Marshal to become a committer and we are pleased to
> > announce that he has accepted.
> >
> > Michael contributed a lot of interesting additions to the project and he
> is
> > very active in the community.
> >
> > Being a committer enables easier contribution to the
> > project since there is no need to go via the patch
> > submission process. This should enable better productivity.
> >
> > Congrats Micheal !
> >
> >
> > Enrico Olivelli
> >
>

Re: New committer: Michael Marshal

[Christophe Bornet]

Awesome ! Congrats Michael !

Le ven. 3 déc. 2021 à 08:32, Enrico Olivelli  a écrit :

> The Project Management Committee (PMC) for Apache  Pulsar
> has invited Michael Marshal to become a committer and we are pleased to
> announce that he has accepted.
>
> Michael contributed a lot of interesting additions to the project and he is
> very active in the community.
>
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
>
> Congrats Micheal !
>
>
> Enrico Olivelli
>

Re: Missing check on .jar files committed to the source repo

[Enrico Olivelli]

Il giorno ven 3 dic 2021 alle ore 10:20 ZhangJian He 
ha scritto:

> Gradle has `gradle-wrapper.jar` too. I think we don't need an automated
> check, the reviewers can find if it's reasonable.
>

For some files there are specific acceptance rules.
But we cannot commit other files that are not needed.


Enrico


>
> Enrico Olivelli  于2021年11月10日周三 16:47写道：
>
> > ping
> >
> >
> > Il giorno ven 5 nov 2021 alle ore 09:23 Enrico Olivelli <
> > eolive...@gmail.com>
> > ha scritto:
> >
> > > Hello,
> > > This patch [1] contains a .jar file that must not be committed to the
> > > source repository.
> > > We generally cannot commit binary files to the source repo, as it won't
> > be
> > > "open source" anymore.
> > >
> > > When we are permitted to commit binary/compiled code, there must be a
> > very
> > > good reason and it must be approved explicitly and noted somewhere
> > (NOTICE
> > > file?)
> > >
> > > My point here is that we are missing some automated check to prevent
> such
> > > accidental commits.
> > > I believe that we have to add a check to be run at every PR validation
> > and
> > > during the release process that our source distribution does not
> contain
> > > compiled code.
> > >
> > > Thoughts ?
> > >
> > > Enrico
> > >
> > > [1] https://github.com/apache/pulsar/pull/12535
> > >
> > >
> >
>

Re: Missing check on .jar files committed to the source repo

[ZhangJian He]

Gradle has `gradle-wrapper.jar` too. I think we don't need an automated
check, the reviewers can find if it's reasonable.

Enrico Olivelli  于2021年11月10日周三 16:47写道：

> ping
>
>
> Il giorno ven 5 nov 2021 alle ore 09:23 Enrico Olivelli <
> eolive...@gmail.com>
> ha scritto:
>
> > Hello,
> > This patch [1] contains a .jar file that must not be committed to the
> > source repository.
> > We generally cannot commit binary files to the source repo, as it won't
> be
> > "open source" anymore.
> >
> > When we are permitted to commit binary/compiled code, there must be a
> very
> > good reason and it must be approved explicitly and noted somewhere
> (NOTICE
> > file?)
> >
> > My point here is that we are missing some automated check to prevent such
> > accidental commits.
> > I believe that we have to add a check to be run at every PR validation
> and
> > during the release process that our source distribution does not contain
> > compiled code.
> >
> > Thoughts ?
> >
> > Enrico
> >
> > [1] https://github.com/apache/pulsar/pull/12535
> >
> >
>

Re: New committer: Michael Marshal

[ZhangJian He]

Congrats Micheal !

PengHui Li  于2021年12月3日周五 17:13写道：

> Congrats Micheal!
>
> Penghui
>
> On Fri, Dec 3, 2021 at 3:32 PM Enrico Olivelli 
> wrote:
>
> > The Project Management Committee (PMC) for Apache  Pulsar
> > has invited Michael Marshal to become a committer and we are pleased to
> > announce that he has accepted.
> >
> > Michael contributed a lot of interesting additions to the project and he
> is
> > very active in the community.
> >
> > Being a committer enables easier contribution to the
> > project since there is no need to go via the patch
> > submission process. This should enable better productivity.
> >
> > Congrats Micheal !
> >
> >
> > Enrico Olivelli
> >
>

Re: New committer: Michael Marshal

[PengHui Li]

Congrats Micheal!

Penghui

On Fri, Dec 3, 2021 at 3:32 PM Enrico Olivelli  wrote:

> The Project Management Committee (PMC) for Apache  Pulsar
> has invited Michael Marshal to become a committer and we are pleased to
> announce that he has accepted.
>
> Michael contributed a lot of interesting additions to the project and he is
> very active in the community.
>
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
>
> Congrats Micheal !
>
>
> Enrico Olivelli
>