Re: New Doc (Broker Load Balancing) is available!

[Yu]

Hi team,

A quick update:

We've recently completed more content about Broker Load Balancing. You can
access the new docs on the Pulsar website as provided below:

- Quick Start [1]: Offers a complete tutorial on getting started with the
broker load balancer using Docker swiftly, accompanied by step-by-step
procedures. It involves setting up ZooKeeper, Bookie, and brokers, creating
topics, and splitting and unloading bundles, with detailed inputs and
outputs provided.

- Migration [2]: Outlines the process of transitioning between different
types of broker load balancers. This section covers considerations on when
and how to migrate and offers insights to ensure a smooth migration
experience with step-by-step instructions.

- Metrics [3]: Presents metrics associated with broker load balancing,
including what (e.g., bundle assignment, resource usage, service unit state
channel, etc) and how to observe. It helps you monitor and analyze the
effectiveness of load balancing within Pulsar clusters.

- Configurations [4]: Shows various configurations related to broker load
balancing, including what (e.g., bundle ownership, bundle unloading, bundle
splitting, etc) and how to configure. It allows you to optimize the
behavior of load balancing based on your specific needs.

- Development [5]: Covers essential concepts and processes for extending
broker load balancer functionalities, including enabling and verifying load
managers, using configuration settings and relevant tools, etc.

Feel free to read the docs and provide any suggestions you may have. We
appreciate your valuable feedback. TIA!

In addition, thanks again for your great guidance! @Demogorgon314
@heesung-sn @D-2-Ed

[1] Quick Start:
https://pulsar.apache.org/docs/next/concepts-broker-load-balancing-quick-start/
[2] Migration:
https://pulsar.apache.org/docs/next/concepts-broker-load-balancing-migration/
[3] Metrics:
https://pulsar.apache.org/docs/next/reference-metrics/#load-balancing
[4] Configurations:
https://pulsar.apache.org/reference/#/next/config/?id=broker-load-balancing-configurations
[5] Development: https://pulsar.apache.org/docs/next/develop-load-manager/

Yu

On Thu, Jul 27, 2023 at 11:04 AM Yubiao Feng
 wrote:

> Hi Yu
>
> It is amazing; thanks for your great work.
>
> Thanks
> Yubiao
>
> On Thu, Jun 29, 2023 at 2:43 PM Yu  wrote:
>
> > Hi team,
> >
> > # New Doc | Broker Load Balancing
> >
> > I am excited to share that the 1st release of our new documentation on
> > "Broker Load Balancing" is available!
> >
> > The "Overview" section is now complete and available on the Pulsar
> website
> > [1].
> >
> > Our goal with this fresh documentation set is to provide you with a
> > comprehensive and systematic understanding of the topic, ensuring a
> > seamless content experience.
> >
> > Moving forward, we are entering the next phase of development, which
> > involves creating detailed "Concept" documents [2].
> >
> > To give you an idea of what to expect, here are our plans:
> >
> > - Broker Load Balancing | Information Architecture Map [3]
> > This document presents a high-level architecture overview, including how
> we
> > address content gaps and reconcile existing documentation.
> >
> > - Broker Load Balancing | Doc Outline [4]
> > This document delves into the specifics of THE development plan,
> providing
> > purpose and context for each section.
> >
> > Feel free to review them and offer any feedback you may have.
> > Your input is essential in ensuring that our documentation meets your
> needs
> > effectively.
> > Thank you!
> >
> > # Ackowledgement
> >
> > Additionally, I would like to extend my gratitude to @Demogorgon314 and
> > @heesung-sn, for your patient guidance and comprehensive technical
> inputs!
> > Your expertise has been invaluable in shaping the quality of our
> > documentation.
> >
> > Lastly, I want to express my appreciation to @D-2-Ed, for your
> professional
> > writing suggestions.
> > Your advice has greatly enhanced the clarity and effectiveness of our
> > documentation.
> >
> > Please find the links below for easy access:
> >
> > [1] Broker Load Balancing | Overview:
> >
> >
> https://pulsar.apache.org/docs/next/concepts-broker-load-balancing-overview/
> > [2] Broker Load Balancing | Concepts (WIP):
> >
> >
> https://docs.google.com/document/d/1hkJpfZgTpRr8k39qNy6_82rGVQrJalVtmUl-OVW78fM/edit
> > [3] Broker Load Balancing | Information Architecture Map:
> > https://xmind.works/share/dzbyKsnS
> > [4] Broker Load Balancing | Doc Outline:
> >
> >
> https://docs.google.com/document/d/1zshyn93XJp8Y-uvYLTnFCrcUWaHxeiTjPqdaUrR6zf0/edit
> >
> > Yu
> >
>

Re: [DISCUSS] Optimizing the findability of Pulsar documentation with SEO strategies

[Yu]

Hi team,

This is our OSPP project -- Optimizing the findability of Pulsar
documentation with SEO strategies  [1], aiming to improve the findability
and searchability of content on the Pulsar documentation website by
applying effective SEO strategies.

If it is good to go, we'll publish a more detailed implementation plan soon.

Feel free to take a look and leave your comments. TIA!

[1] https://summer-ospp.ac.cn/org/prodetail/23e980570?list=org=org

On Mon, Jul 31, 2023 at 10:03 AM yuxuan zhang 
wrote:

> Hi Pulsar Community,
>
> I would like to propose earning featured snippets for Pulsar Doc.
>
> *## Motivation*
>
> Featured snippets [1] provide a brief text that directly answers the
> searcher's query. In Google search results, featured snippets appear at the
> top where usually called “Page 0” and it contributes significantly to the
> pageview of a website.
>
> Among all SEO [2] (Search Engine Optimization) strategies, earning a
> featured snippet is the primary and most effective method. Therefore, I
> would like to propose making some small modifications to the Pulsar
> documentation to earn more featured snippets, thereby improving pageview
> numbers.
>
> [1] https://developers.google.com/search/docs/appearance/featured-snippets
> [2]
> https://developers.google.com/search/docs/fundamentals/seo-starter-guide
>
> *## How to earn more featured snippets for Pulsar doc*
>
> The Pulsar doc already has a certain level of authority. By standardizing
> the format to make the content easily understandable by search engines,
> there is a high probability of generating featured snippets.
>
> The types of featured snippets that Pulsar doc can generate typically
> correspond to definition, unordered list, and ordered list.
>
> By drawing on some SEO best practices and studying how other websites
> create featured snippets, I have summarized the techniques for generating
> featured snippets as follows:
>
>
>- definition
>
> Google typically uses definition boxes to answer searches for "what is
> (are) X". The average length of these snippets ranges from 40 to 60 words.
>
> To generate this type of featured snippet, we need to explicitly write
> sentences in the document using the structure "X is (are) …" and emphasize
> the defining part.
>
>
>- unordered list
>
> This is a list of displayed items that do not need to be arranged in a
> specific order.
>
> To generate this type of featured snippet, Place each item on a separate
> line and precede it with a bullet point for the list.
>
>
>
>- ordered list
>
> This is a list displayed in a specific order, corresponding to the "How to
> ..." type of query.
>
> To generate this type of featured snippet, we should use a series of
> summary-style subheadings in the body of the content and explicitly define
> each step by adding the relevant phrases like "Step 1 Step 2 Step 3 ..." or
> "1. 2. 3. …" before them.
>
> For more detailed information, please see this discussion [3].
>
> [3] https://github.com/apache/pulsar/discussions/20897
>
> *## Schedule*
>
> In the next two months, I will do SEO for Pulsar Doc [4], which includes
> optimizing the content to earn featured snippets and adding meta
> descriptions [5] and alt tags [6].
>
> [4] https://pulsar.apache.org/docs/next/
> [5] https://developers.google.com/search/docs/appearance/snippet
> [6] https://developers.google.com/search/docs/appearance/google-images
>
> I welcome any feedback or thoughts you may have on this issue.
>
> Best,
> Yuxuan.
>

Re: Pulsar doc: reduced supported versions

[Yu]

Hi Yubiao,

Thanks for caring about docs!

However, 2.9.x ~ 2.2.0 docs are not actively maintained. For the doc
maintenance life cycle, we keep it the same as the code maintenance life
cycle, that is, now we only maintain NEXT, 3.0.x, 2.11.x, and 2.10.x (The
last 2 LTS releases and the last 2 feature releases are supported [1])

[1]
https://pulsar.apache.org/contribute/release-policy/#release-frequency-and-support-expectation

Yu


On Thu, Jul 27, 2023 at 11:02 AM Yubiao Feng
 wrote:

> The current list of pulsar doc-supported versions is as follows:
> - 2.11.x Documentation
> - 2.10.x Documentation
> - 2.9.x Documentation
> - 2.8.x Documentation
> - 2.7.5 Documentation
> - 2.7.4 Documentation
> - 2.7.3 Documentation
> - 2.7.2 Documentation
> - 2.7.1 Documentation
> - 2.7.0 Documentation
> - 2.6.4 Documentation
> - 2.6.3 Documentation
> - 2.6.2 Documentation
> - 2.6.1 Documentation
> - 2.6.0 Documentation
> - 2.5.2 Documentation
> - 2.5.1 Documentation
> - 2.5.0 Documentation
> - 2.4.2 Documentation
> - 2.4.1 Documentation
> - 2.4.0 Documentation
> - 2.3.2 Documentation
> - 2.3.1 Documentation
> - 2.3.0 Documentation
> - 2.2.1 Documentation
> - 2.2.0 Documentation
>
> The latest major version of Pulsar only supports the last minor version.
> For example, 2.11.x only supports maintaining the last minor version of
> doc, so why does 2.6.x support so many minor versions? I suggest supporting
> only the last minor release of each major release.
>
> Thanks
> Yubiao Feng
>

Re: New Doc (Broker Load Balancing) is available!

[Yu]

Hi team,

A quick update:

We've recently completed more content about Broker Load Balancing. You can
access the new docs on the Pulsar website as provided below:

- Use cases [1]: Explore various scenarios where broker load balancing can
be leveraged, including workload distribution for scaling and achieving
high availability with fault tolerance.

- Features [2]: Discover the key features and capabilities offered by
broker load balancing.

- Benefits [3]: Learn about the advantages of using broker load balancing,
such as improved efficiency, performance, availability, scalability, and
more.

- Types [4]: Gain insights into different types of broker load balancers
and make informed choices. This section includes a side-by-side comparison
of modular and extensible broker load balancers, covering aspects like
architecture, observability, flexibility, performance tests, and more.

Feel free to review the docs and provide any comments you may have. We
appreciate your valuable feedback. TIA!

[1]
https://pulsar.apache.org/docs/next/concepts-broker-load-balancing-use-cases/
[2]
https://pulsar.apache.org/docs/next/concepts-broker-load-balancing-features/
[3]
https://pulsar.apache.org/docs/next/concepts-broker-load-balancing-benefits/
[4]
https://pulsar.apache.org/docs/next/concepts-broker-load-balancing-types/

In addition, thanks again for your great guidance! @Demogorgon314 and
@heesung-sn @D-2-Ed

Yu

On Thu, Jul 20, 2023 at 10:17 PM Yu  wrote:

> Hi team,
>
> FYI: we have completed more docs about Broker Load Balancing. You can
> access them on the Pulsar website as provided below:
>
> - Concepts [1], including comprehensive explanations, vivid illustrations,
> and intuitive examples for complex concepts, covering broker load
> balancing, topic bundling, bundle assignment, bundle splitting and its
> algorithms, bundle unloading and its strategies, and more!
>
> - Metrics [2], demonstrating various metrics that can be monitored for the
> extensible load balancer.
>
> Feel free to read and give your feedback. TIA!
>
> [1]
> https://pulsar.apache.org/docs/next/concepts-broker-load-balancing-concepts/
> [2] https://pulsar.apache.org/docs/next/reference-metrics/
>
> On Thu, Jun 29, 2023 at 2:42 PM Yu  wrote:
>
>> Hi team,
>>
>> # New Doc | Broker Load Balancing
>>
>> I am excited to share that the 1st release of our new documentation on
>> "Broker Load Balancing" is available!
>>
>> The "Overview" section is now complete and available on the Pulsar
>> website [1].
>>
>> Our goal with this fresh documentation set is to provide you with a
>> comprehensive and systematic understanding of the topic, ensuring a
>> seamless content experience.
>>
>> Moving forward, we are entering the next phase of development, which
>> involves creating detailed "Concept" documents [2].
>>
>> To give you an idea of what to expect, here are our plans:
>>
>> - Broker Load Balancing | Information Architecture Map [3]
>> This document presents a high-level architecture overview, including how
>> we address content gaps and reconcile existing documentation.
>>
>> - Broker Load Balancing | Doc Outline [4]
>> This document delves into the specifics of THE development plan,
>> providing purpose and context for each section.
>>
>> Feel free to review them and offer any feedback you may have.
>> Your input is essential in ensuring that our documentation meets your
>> needs effectively.
>> Thank you!
>>
>> # Ackowledgement
>>
>> Additionally, I would like to extend my gratitude to @Demogorgon314 and
>> @heesung-sn, for your patient guidance and comprehensive technical inputs!
>> Your expertise has been invaluable in shaping the quality of our
>> documentation.
>>
>> Lastly, I want to express my appreciation to @D-2-Ed, for your
>> professional writing suggestions.
>> Your advice has greatly enhanced the clarity and effectiveness of our
>> documentation.
>>
>> Please find the links below for easy access:
>>
>> [1] Broker Load Balancing | Overview:
>> https://pulsar.apache.org/docs/next/concepts-broker-load-balancing-overview/
>> [2] Broker Load Balancing | Concepts (WIP):
>> https://docs.google.com/document/d/1hkJpfZgTpRr8k39qNy6_82rGVQrJalVtmUl-OVW78fM/edit
>> [3] Broker Load Balancing | Information Architecture Map:
>> https://xmind.works/share/dzbyKsnS
>> [4] Broker Load Balancing | Doc Outline:
>> https://docs.google.com/document/d/1zshyn93XJp8Y-uvYLTnFCrcUWaHxeiTjPqdaUrR6zf0/edit
>>
>> Yu
>>
>

Re: [ANNOUNCE] Zili Chen (tison) as new PMC member in Apache Pulsar

[Yu]

Congrats!

On Sat, Jul 22, 2023 at 9:53 AM ZhangJian He  wrote:

> Congratulations
>
> Thanks
> ZhangJian He
>
>
> On Sat, 22 Jul 2023 at 01:19, Lari Hotari  wrote:
>
> > Congratulations, Tison!
> >
> > -Lari
> >
> > On Fri, 21 Jul 2023, 20.05 Michael Marshall, 
> wrote:
> >
> > > Hi Pulsar Community,
> > >
> > > The Apache Pulsar Project Management Committee (PMC) has invited Zili
> > Chen
> > > (https://github.com/tisonkun) as a member of the PMC and we are
> > > pleased to announce that tison has accepted.
> > >
> > > tison is very active in the community by contributing and reviewing
> > > many PRs, actively engaging on the mailing list, triaging GitHub
> > > Issues, and helping out with the website.
> > >
> > > On behalf of the Pulsar PMC, welcome and congratulations to tison!
> > >
> > > Best,
> > > Michael
> > >
> >
>

Re: New Doc (Broker Load Balancing) is available!

[Yu]

Hi team,

FYI: we have completed more docs about Broker Load Balancing. You can
access them on the Pulsar website as provided below:

- Concepts [1], including comprehensive explanations, vivid illustrations,
and intuitive examples for complex concepts, covering broker load
balancing, topic bundling, bundle assignment, bundle splitting and its
algorithms, bundle unloading and its strategies, and more!

- Metrics [2], demonstrating various metrics that can be monitored for the
extensible load balancer.

Feel free to read and give your feedback. TIA!

[1]
https://pulsar.apache.org/docs/next/concepts-broker-load-balancing-concepts/
[2] https://pulsar.apache.org/docs/next/reference-metrics/

On Thu, Jun 29, 2023 at 2:42 PM Yu  wrote:

> Hi team,
>
> # New Doc | Broker Load Balancing
>
> I am excited to share that the 1st release of our new documentation on
> "Broker Load Balancing" is available!
>
> The "Overview" section is now complete and available on the Pulsar website
> [1].
>
> Our goal with this fresh documentation set is to provide you with a
> comprehensive and systematic understanding of the topic, ensuring a
> seamless content experience.
>
> Moving forward, we are entering the next phase of development, which
> involves creating detailed "Concept" documents [2].
>
> To give you an idea of what to expect, here are our plans:
>
> - Broker Load Balancing | Information Architecture Map [3]
> This document presents a high-level architecture overview, including how
> we address content gaps and reconcile existing documentation.
>
> - Broker Load Balancing | Doc Outline [4]
> This document delves into the specifics of THE development plan, providing
> purpose and context for each section.
>
> Feel free to review them and offer any feedback you may have.
> Your input is essential in ensuring that our documentation meets your
> needs effectively.
> Thank you!
>
> # Ackowledgement
>
> Additionally, I would like to extend my gratitude to @Demogorgon314 and
> @heesung-sn, for your patient guidance and comprehensive technical inputs!
> Your expertise has been invaluable in shaping the quality of our
> documentation.
>
> Lastly, I want to express my appreciation to @D-2-Ed, for your
> professional writing suggestions.
> Your advice has greatly enhanced the clarity and effectiveness of our
> documentation.
>
> Please find the links below for easy access:
>
> [1] Broker Load Balancing | Overview:
> https://pulsar.apache.org/docs/next/concepts-broker-load-balancing-overview/
> [2] Broker Load Balancing | Concepts (WIP):
> https://docs.google.com/document/d/1hkJpfZgTpRr8k39qNy6_82rGVQrJalVtmUl-OVW78fM/edit
> [3] Broker Load Balancing | Information Architecture Map:
> https://xmind.works/share/dzbyKsnS
> [4] Broker Load Balancing | Doc Outline:
> https://docs.google.com/document/d/1zshyn93XJp8Y-uvYLTnFCrcUWaHxeiTjPqdaUrR6zf0/edit
>
> Yu
>

Re: Failover Subscription - consumer assignment logic discussion

[Yu]

Hi Penghui and Girish,

Thanks for your discussions and technical guidance!

I've optimized the docs in https://github.com/apache/pulsar-site/pull/633,
could you PTAL?

Anyone else who wants to take a look and comment, feel free! Thanks!

Yu

On Tue, Jul 4, 2023 at 8:31 AM PengHui Li  wrote:

> > I was also thinking that from a user perspective, one would think that a
> lower priority consumer is meant for backup in case one active consumer
> goes down - which also doesn't work like that.
>
> Yes, it makes sense. We will try to think more about that to find
> a solution to make Failover subscription better. I still have no idea
> for now. A coordinator can help but it will introduce complexity to
> Pulsar.
>
> Regards,
> Penghui
>
>
> On Mon, Jul 3, 2023 at 11:20 PM Girish Sharma 
> wrote:
>
> > Hello PengHui,
> >
> > On Mon, Jul 3, 2023 at 8:39 PM PengHui Li  wrote:
> >
> > >
> > > Got it, for the Failover subscription, the new consumer caused the
> active
> > > consumer
> > > shift. I think we can make some improvements to this part to make sure
> > the
> > > new active
> > > consumer will only get messages after the previous active consumer
> acked
> > > all the received
> > > message unless the previous active consumer disconnected.
> > >
> > > I think this will greatly help maintain the ordering guarantees per
> > partition.
> >
> >
> > >
> > > If all the consumers with the highest priority are disconnected, then
> > > the consumers with a lower priority will be peeked. The Shared
> > subscription
> > > have different behavior. It will select the lower priority consumer if
> > all
> > > highest
> > > priority consumers don't have available permits. I think the challenge
> > for
> > > Failover subscription is the broker needs to shift the active consumer
> > > according
> > > to the available permits. But it could be considered in a different
> > active
> > > consumer assigner implementation like Kafka's consumer group
> coordinator,
> > > you can have different policies.
> > >
> > > Right, in case of shared subs, the lower priority consumers are used
> more
> > often since permits are considered and thus, slow consumers are detected
> > quickly.
> >
> > In Failover, the current logic can lead to a single remaining active
> > consumer consuming from all partitions, while multiple lower priority
> > consumers are on standby. That single higher priority consumer may not be
> > able to keep up with the topic throughput.
> > We cannot also directly use the same behavior as Shared subscription here
> > because that would again lead to out of order delivery of messages.
> >
> > I do not have a solution in mind here right now but I will come up with
> > something so that the load balancing can be better, utilizing lower
> > priority consumers as well.
> >
> > I was also thinking that from a user perspective, one would think that a
> > lower priority consumer is meant for backup in case one active consumer
> > goes down - which also doesn't work like that.
> >
> > Regards
> >
> >
> >
> > > Regards,
> > > Penghui
> > >
> > > On Mon, Jul 3, 2023 at 7:52 PM Girish Sharma 
> > > wrote:
> > >
> > > > Hello PengHui,
> > > > Thank you for the reply. Adding comments inline below with a few
> > > concerns.
> > > >
> > > > On Mon, Jul 3, 2023 at 4:38 PM PengHui Li 
> wrote:
> > > >
> > > > > Hi Girish,
> > > > >
> > > > > Thanks for raising the discussion.
> > > > >
> > > > > I can confirm that your understanding is correct, and the document
> > > > > is confusing. If there are four consumers connected to a
> partitioned
> > > > topic
> > > > > with two partitions, each partition will have four connected
> > consumers
> > > > but
> > > > > only one active consumer. The document said two consumers are
> > connected
> > > > > to each partition is wrong. We will try to improve the document,
> and
> > > your
> > > > > contribution is welcome if you want to improve it.
> > > > >
> > > > > Yes, the part where it shows only 2 consumers are connected is
> > > > misleading,
> > > > but from information point of view, it is still okay to show only 2
> in
> > > the
> > &

Re: Request to contribute to Apache Pulsar JIRA maintenance and documentation

[Yu]

Hi Yuvaraj,

Thank you for your willingness to contribute to the Pulsar documentation!

Feel free to select your desired issues from
https://github.com/apache/pulsar/issues?q=is%3Aopen+is%3Aissue+label%3Adoc-required
.

You can find the documentation contribution guide at
https://pulsar.apache.org/contribute/document-intro/, and don't hesitate to
reach out to me for any assistance or to have your pull requests reviewed.

Yu


On Fri, Jul 7, 2023 at 8:50 AM Yuvaraj Madeshwaran 
wrote:

> Dear Apache Pulsar Foundation,
>
> I am writing to express my interest in contributing to the JIRA dashboard
> maintenance and documentation of Apache Pulsar Github repos. I have
> developed a deep understanding of the software and JIRA. I am also
> proficient in writing technical documentation.
>
> I believe that my skills and experience would be a valuable asset to the
> Apache Pulsar project. I am a highly motivated and detail-oriented
> individual, and I am always willing to go the extra mile. I am also a quick
> learner, and I am always eager to learn new things.
>
> I am particularly interested in contributing to the following areas:
> JIRA board maintenance
> Documentation
> Testing
>
> I am available to contribute on a part-time basis. I have attached my
> resume for your review. I have also included a link to my GitHub profile
> https://github.com/yuvarajmms .
>
> Thank you for your time and consideration. I look forward to hearing from
> you soon.
>
> Sincerely,
> Yuvaraj Madheswaran
>

Re: [VOTE] PIP-276: Add metric `pulsar_topic_load_times

[Yu]

Thank you all.
We've added the doc in https://github.com/apache/pulsar-site/pull/631

On Mon, Jul 3, 2023 at 11:15 AM guo jiwei  wrote:

> Close the vote with 4(+1 binding) 2(+1 non-binding) 0(-1)
>
> binding:
>  Hang
>  Yunze
>  Mattison
>  Penghui
>
> non-binding
>  Yubiao
>  Asaf
>
>
> Regards
> Jiwei Guo (Tboy)
>
>
> On Mon, Jun 26, 2023 at 10:30 PM Hang Chen  wrote:
>
> > +1 (binding)
> >
> > Thanks,
> > Hang
> >
> > Yunze Xu  于2023年6月26日周一 19:59写道：
> > >
> > > +1 (binding)
> > >
> > > Thanks,
> > > Yunze
> > >
> > >
> > >
> > >
> > > > On Jun 20, 2023, at 10:53, mattisonc...@gmail.com wrote:
> > > >
> > > > +1(binding)
> > > >
> > > > Best,
> > > > Mattison
> > > > On 20 Jun 2023 at 10:45 +0800, PengHui Li ,
> wrote:
> > > >> +1 (binding)
> > > >>
> > > >> Thanks,
> > > >> Penghui
> > > >>
> > > >> On Tue, Jun 20, 2023 at 10:40 AM Yubiao Feng
> > > >>  wrote:
> > > >>
> > > >>> Voting +1 (non-binding)
> > > >>>
> > > >>> Thanks
> > > >>> Yubiao Feng
> > > >>>
> > > >>> On Mon, Jun 19, 2023 at 5:21 PM Asaf Mesika  >
> > wrote:
> > > >>>
> > > > Voting +1 (non-binding)
> > > >
> > > > On Fri, Jun 16, 2023 at 12:23 PM guo jiwei  >
> > wrote:
> > > >
> > > >>> @Asaf Thanks, I have addressed the comment.
> > > >>>
> > > >>> Regards
> > > >>> Jiwei Guo (Tboy)
> > > >>>
> > > >>>
> > > >>> On Fri, Jun 16, 2023 at 3:55 AM Asaf Mesika <
> > asaf.mes...@gmail.com>
> > > > wrote:
> > > >>>
> > > > -1 (non-binding)
> > > >
> > > > I'm perfectly ok with the idea; just please fix the document.
> > It
> > > >>> looks
> > > >>> too
> > > > messy. Even 1 paragraph changes can look neat and clean.
> > > > I left notes in the draft PR you opened for the pip.
> > > >
> > > > I'll change my non-binding vote once that's done.
> > > >
> > > > On Thu, Jun 15, 2023 at 11:07 AM guo jiwei <
> > techno...@apache.org>
> > > > wrote:
> > > >
> > > >>> Hi, community:
> > > >>> The metrics are all started with `pulsar_`, so that both
> > users
> > > > and
> > > >>> operators can quickly find the metrics of the entire system
> > through
> > > >>> this prefix. However, due to some other reasons, it was
> > found that
> > > >>> `topic_load_times` was missing the prefix, so want to get
> it
> > right.
> > > >>> In the master branch :
> > > >>> * `pulsar_topic_load_times`: Add this new metric which has
> > the
> > > >>> same
> > > >>> meaning as `topic_load_times`
> > > >>> * `topic_load_times`: Mark this metric as deprecated and
> > > >>> remove
> > > >>> it
> > > > in
> > > >>> the next version
> > > >>>
> > > >>> PIP: https://github.com/apache/pulsar/pull/20518
> > > >>>
> > > >>> Regards
> > > >>> Jiwei Guo (Tboy)
> > > >>>
> > > >
> > > >>>
> > > >
> > > >>>
> > >
> >
>

New Doc (Broker Load Balancing) is available!

[Yu]

Hi team,

# New Doc | Broker Load Balancing

I am excited to share that the 1st release of our new documentation on
"Broker Load Balancing" is available!

The "Overview" section is now complete and available on the Pulsar website
[1].

Our goal with this fresh documentation set is to provide you with a
comprehensive and systematic understanding of the topic, ensuring a
seamless content experience.

Moving forward, we are entering the next phase of development, which
involves creating detailed "Concept" documents [2].

To give you an idea of what to expect, here are our plans:

- Broker Load Balancing | Information Architecture Map [3]
This document presents a high-level architecture overview, including how we
address content gaps and reconcile existing documentation.

- Broker Load Balancing | Doc Outline [4]
This document delves into the specifics of THE development plan, providing
purpose and context for each section.

Feel free to review them and offer any feedback you may have.
Your input is essential in ensuring that our documentation meets your needs
effectively.
Thank you!

# Ackowledgement

Additionally, I would like to extend my gratitude to @Demogorgon314 and
@heesung-sn, for your patient guidance and comprehensive technical inputs!
Your expertise has been invaluable in shaping the quality of our
documentation.

Lastly, I want to express my appreciation to @D-2-Ed, for your professional
writing suggestions.
Your advice has greatly enhanced the clarity and effectiveness of our
documentation.

Please find the links below for easy access:

[1] Broker Load Balancing | Overview:
https://pulsar.apache.org/docs/next/concepts-broker-load-balancing-overview/
[2] Broker Load Balancing | Concepts (WIP):
https://docs.google.com/document/d/1hkJpfZgTpRr8k39qNy6_82rGVQrJalVtmUl-OVW78fM/edit
[3] Broker Load Balancing | Information Architecture Map:
https://xmind.works/share/dzbyKsnS
[4] Broker Load Balancing | Doc Outline:
https://docs.google.com/document/d/1zshyn93XJp8Y-uvYLTnFCrcUWaHxeiTjPqdaUrR6zf0/edit

Yu

Re: [Site] New "How does Pulsar work" homepage section

[Yu]

Thank you all!
Left some comments, PTAL.

On Wed, Jun 21, 2023 at 5:00 AM Kiryl Valkovich 
wrote:

> Hi, Pulsar developers’ community!
>
>
>
> At the recent Pulsar Virtual Summit Europe 2023, we introduced the major
> pulsar.apache.org site redesign.
>
> We believe that it makes a good first impression of the Apache Pulsar and
> helps to attract more users and contributors to the project in the long
> term.
>
>
>
> In the next few days, we are going to introduce a new "How does Pulsar
> work" section to the homepage.
>
>
>
> Beautiful informative illustration designed by Emidio Cardeira gives a
> high-level understanding of Pulsar building blocks and their relations.
>
> Under the illustration, we placed a brief description purpose of each of
> the building blocks.
>
>
>
> Live demo:
> https://pulsar-site-git-how-pulsar-work-screen-teal-tools.vercel.app/
>
> PR: https://github.com/apache/pulsar-site/pull/614
>
>
>
> Thanks Asaf Mesika for curating the site redesign project and tison for
> reviewing the PRs.
>
>
>
> Currently, we are working on new Pulsar Community and Pulsar Features
> pages.
>
> You can track the design progress and leave your comments in Figma:
>
>
>
> -
> https://www.figma.com/file/0jERoA2DTlfQoj1uH09FxQ/Pulsar-website?node-id=368-658=8e5jjfIqCrgtRy9w-0
>
>
>
> -
> https://www.figma.com/file/0jERoA2DTlfQoj1uH09FxQ/Pulsar-website?type=design=1223-1864=aoWstTjkAYfo5Top-0
>
>
>
> Also, if you want to share your thoughts on content, and how to show and
> explain Pulsar concepts in an easy to understand way, please do it in this
> mailing list or join the #pip_249 channel in the Apache Pulslar community
> Slack.
>
>
>
> Best,
>
> Kiryl
>
>

Re: Look at the fresh Apache Pulsar website!

[Yu]

Hi Kiryl,

Thanks for your great contribution. The new look is more clean and
professional!

I've checked the whole design and commented on the doc layout [1]. Can you
please take a look? Thank you!

[1] https://github.com/apache/pulsar-site/pull/560#issuecomment-1553900225

On Thu, May 18, 2023 at 5:13 PM Kiryl Valkovich 
wrote:

> Hi,
>
> In PIP-249, Asaf Mesika
> proposed the Pulsar website redesign plan.
> In short, the point is that the website should reflect that Pulsar is a
> modern and well-maintained technology.
>
> Emidio Cardeira prepared the home page design, and we at Teal Tools<
> https://teal.tools/> took care of the coding part.
> Big thanks to tison for the PR review and technical support.
>
> The current changes affect only the visual look.
> Further site content improvements will be done iteratively. I invite you
> to look at PIP-261 by Asaf.
>
> Feel free to express your thoughts and tell us about some bugs.
> The PR will be merged in the next few days.
>
> Links:
> - Demo: https://pulsar-site-pip-249.vercel.app/
> - PIP-249: https://github.com/apache/pulsar/issues/19611
> - PIP-249 PR: https://github.com/apache/pulsar-site/pull/560
>
>
> Best regards
> --
> Kiryl Valkovich
> Teal Tools Inc.
>
>

CFP: OSPP 2023 contributor applications open!

[Yu]

Hi team,

Contributor applications for Open Source Promotion (OSPP) 2023 [1] are now
open!

Open-source beginners or anyone interested in Pulsar are welcome to apply
from now until **June 3 15:00 UTC+8**.

This year we have a new project called *Optimizing the Findability of
Pulsar Documentation with SEO Strategies* [2].

Feel free to submit your application if interested or forward this to your
network. Thank you!

[1] https://summer-ospp.ac.cn/

[2] Project details:
https://summer-ospp.ac.cn/org/prodetail/23e980570?list=org=org

Yu

Re: [VOTE] PIP-261: Restructure Getting Started section

[Yu]

+1 (binding)
It's time to have a frictionless onboarding experience!

On Mon, May 8, 2023 at 9:21 AM Hang Chen  wrote:

> +1 (binding)
>
> Best,
> Hang
>
> tison  于2023年5月7日周日 20:32写道：
> >
> > +1 (non-binding)
> >
> > N.B. IIRC PMC members have binding votes.
> >
> > Best,
> > tison.
> >
> >
> > Yunze Xu  于2023年5月7日周日 20:12写道：
> >
> > > +1 (binding)
> > >
> > > Thanks,
> > > Yunze
> > >
> > > On Sun, May 7, 2023 at 5:20 PM Asaf Mesika 
> wrote:
> > > >
> > > > Hi,
> > > >
> > > > PIP-261 as been opened for quite some time, garnered feedback from 3
> > > > people, which was implemented in the PIP.
> > > >
> > > > It is time to start the vote.
> > > >
> > > > PIP: https://github.com/apache/pulsar/issues/19912
> > > >
> > > > Thanks!
> > > >
> > > > Asaf
> > >
>

Re: CFP for ASF Conference Asia 2023

[Yu]

Hi Dianjin,

Thanks for your reminder!

For the past several years, I attended this awesome conference and gave
some talks about "Apache Pulsar" and "Content Experience" [1]. The ideas
exchanged at this conference helped me think more deeply and make
continuous contributions to Pulsar, so I plan to participate this year and
will submit a proposal about "The Secret to Great Developer Experience is
Killer Content".

Feel free to check my previous talks about Pulsar and leave suggestions if
you're interested. Thanks!

Some talks are:
- Cracking the Code of Information Architecture (Taking Apache Pulsar as an
Example)
- Inside Apache Pulsar’s Content Strategy

Slides and videos are available at
https://docs.google.com/document/d/1Ec1W0RbpNf11h1OhaDP0wgjGB_CC6jAb94iLY4Ziqx8/edit#

Yu


On Sat, May 6, 2023 at 4:25 PM Dianjin Wang  wrote:

> Hi there,
>
> The first-ever, in-person ASF Conference Asia 2023 will be held in Beijing
> on August 18-20, 2023. CFP has been opened and will close by Tuesday, Jun
> 6th, 2022 8:00 AM (Beijing time - UTC+8). Don't hesitate to submit your
> talks on Apache messaging/streaming and more technologies.
>
> You can see more details here: https://apachecon.com/acasia2023/cfp.html.
>
> Best,
> Dianjin Wang
>

Re: Call for projects and mentors for OSPP 2023

[Yu]

Hi Dianjin,

Thanks for your reminder!

Please check my application here (
https://docs.google.com/document/d/1fSVi1ELO7hGSF6_Cm1O9A-kw7covij882_cajLg4Jzs/edit#),
which is more user-friendly to read and re-use info.

Also, attach here for your quick reference.

English Version

# Project Info

## Project Name

Optimizing the findability of Pulsar documentation with SEO strategies

## Project Description

Recently, the Apache Pulsar community has witnessed robust and energetic
growth with faster release iterations and comprehensive documentation,
providing delightful experiences for Pulsar users. As more and more users
search Pulsar-relevant content on Google, the findability of Pulsar
documentation is increasingly important since higher organic search
rankings can build brand awareness and enhance competitiveness. So this
project aims to improve the findability and searchability of content on the
Pulsar documentation website by applying effective SEO strategies. It
includes but is not limited to the following aspects:

- Provide recommendations and make changes accordingly: perform an audit
(criteria + verifications) of the Pulsar documentation and provide
recommendations (issues + priorities) for improvement that support the
Pulsar user journey.

- Earn featured snippets to set Pulsar documentation “position zero” on
Google search results.

- Add description metadata to increase click-through rates to Pulsar
documentation by showing appealing excerpts.

- Add alt tags for images to enable search engines to crawl visuals and
empower screen readers to process images.

### References

- Pulsar documentation website: https://pulsar.apache.org/docs/next/

- Task info | Optimizing Pulsar SEO:
https://docs.google.com/document/d/1xGvp7msOYGjh-YDI1JtJ_ORWACEPWnBlhMMkZbylefQ/edit#heading=h.14qgj6cz

## Difficulty Level

[ ] Basic

[x] Advanced

## Project Validation Requirements

- For the project

1) Submit a report of improvement suggestions for Pulsar documentation and
corresponding documentation changes.

2) Improve SEO for the Pulsar documentation website by earning “feature
snippets”, adding “description metadata”, and inserting “alt tags”.

3) Submit a performance comparison report of SEO results for Pulsar
documentation.

4) Document best practices for Pulsar SEO implementation.

- For the student

Acquire new skills and gain useful experience to level up your portfolio.
For example,

Learn the ins and outs of open source by being mentored by experienced
community members.

Strengthen your abilities of communication and collaboration by balancing
requirements and resolving issues.

Build your network by deeply working with industry veterans.

## Project Technical Requirements

- Strong communication, problem-solving, and holistic thinking abilities.

- Excellent skills in English and technical writing.

- Familiarity with Docs as Code (e.g., Git, Markdown, Docusaurus, Swagger).

- Previous experience in open-source projects.

- Proficiency in any programming language or major in computer science is
preferred.

## Project Repo

- Pulsar documentation and website repo:
https://github.com/apache/pulsar-site

- Pulsar code repo: https://github.com/apache/pulsar

# Mentor Info

## Mentor Name

Yu Liu

## Mentor Email

li...@apache.org

y...@streamnative.io

Do not hesitate to reach out to me if you have any questions or suggestions
on this project. Thank you!

Chinese Version

# 项目信息

## 项目名称

优化 SEO 策略 | 提升 Pulsar 文档的搜索可见性

## 项目介绍

最近几年，Apache Pulsar 社区发展迅猛，版本迭代速度快且文档内容丰富，给用户带来了不少惊喜体验。如今，越来越多的用户在网上搜索
Pulsar 内容，官方文档的搜索可见性也愈发重要（更高的自然搜索排名能提升项目的知名度和竞争力）。因此，本项目旨在通过优化 SEO 策略，增强
Pulsar 文档的搜索可见性，包括但不限于以下任务：

- 提高文档质量：从 Pulsar 用户旅程视角出发，全盘审阅 Pulsar 文档，找出问题、提出建议并提交相应更改。

- 实现 featured snippets：优化文档内容，使 Pulsar 文档作为 featured snippets，显示为 Google
搜索的第一结果，提高文档点击率。

- 增加元数据：为文档增加描述性元数据（descrption），优化 Google 搜索结果中的摘要，提升搜索结果的质量和相关性。

- 增加 alt 标签：为图片增加 alt 标签，增强内容的可读性。

### 参考信息

- Pulsar 文档官网：https://pulsar.apache.org/docs/next/

- 优化 Pulsar SEO | 待完成任务 + 背景信息：
https://docs.google.com/document/d/1xGvp7msOYGjh-YDI1JtJ_ORWACEPWnBlhMMkZbylefQ/edit#

## 难度

[ ] 基础

[x] 高级

## 项目产出要求

- 对于项目而言：

1）提交关于「如何改进 Pulsar 文档」的报告和相应的文档更改。

2）实现 featured snippets、增加描述性元数据、增加 alt 标签。

3）提交关于「Pulsar 文档 SEO 结果优化前后」的性能对比报告。

4）提交关于「如何提升 Pulsar 文档 SEO 结果」的最佳实践。

- 对于学生而言：

希望你能打开视野，收获有利于今后人生发展的软硬技能。例如，了解开源社区的运作方式和最佳实践、增进沟通协调和平衡多方需求能力、拓展职场社交人脉等。最重要的是，找到你喜欢并擅长的事，持续深耕。

## 项目技术要求

希望你具备以下能力：

- 优秀的沟通力、问题解决力和全局思维。

- 优秀的英语技术写作能力。

- 熟悉 Docs as Code（例如，Git, Markdown, Docusaurus, Swagger)。

- 具备开源社区经验。

- 技术背景是加分项。

## 项目仓库

- Pulsar 文档和网站仓库：https://github.com/apache/pulsar-site

- Pulsar 代码仓库：https://github.com/apache/pulsar

# 导师信息

## 导师名字

Yu Liu

## 导师邮箱

li...@apache.org

y...@streamnative.io

如果你有任何问题或建议，欢迎随时联系我，谢谢！

On Sun, Apr 23, 2023 at 9:41 PM Dianjin Wang  wrote:

> Hi,
>
> If you're inserted in being the mentor, please send your project info by
> 04/25. We need to submit all the projects on 04/26 

Re: Call for projects and mentors for OSPP 2023

[Yu]

Thanks Dianjing!

This is an activity worth attending based on my previous experience. As a
mentor for OSPP 2021 and 2022, I collaborated with some students and
@urfreespace to create fresh content experiences for Pulsar, such as
Introducing a Bot to Improve the Efficiency of Developing Docs [1] and
Automating Documentation Workflows.

I'll continue to apply to participate as a mentor this year to infuse more
new blood into our community with the project targeting improving content
and website. Will send the application to you later.

[1]
https://docs.google.com/document/d/1bQfZkSu5nG1tNycpmXXtUFn-Z5-h-uqHv6IXsCEySQ8/edit

On Tue, Apr 11, 2023 at 10:53 AM Dianjin Wang  wrote:

> Hi all,
>
> Glad to share that Apache Pulsar is listed at the OSPP 2023 again. This
> year, the Pulsar community can open 7 projects at most.
>
> For OSPP 2023, the project idea will be open from 4/04, 2023 to 04/28,
> 2023(UTC+8). If you have great ideas, please reply to this email by
> following the project template. Then I can help you to submit them.
>
> OSPP asks that Pulsar committers, PMC members, and contributors be the
> mentors; a mentor can only mentor one project. Both mentors and students
> will receive financial awards for completed projects.
>
> You may want to know about OSPP 2022, so refer to this email[1] for
> details.
>
> --
> [Template]
>
> ## Project Info
> Project Name:
> Project Description: (at most 1000 words)
> Difficulty Level:
> - [ ] Basic
> - [ ] Advanced
>
> Project Output Requirements:
> Item 1:__
> Item 2:__
> Item 3:__
> …
>
> Project Technical Requirements:
> Item 1:__
> Item 2:__
> Item 3:__
> …
>
> ## Mentor Info
> Mentor Name:
> Mentor Email:
> --
>
> [1] https://lists.apache.org/thread/7pplcd4c35qjzt2o58qxykkty8qqxvt3
>
> Best,
> Dianjin Wang
>

Re: [DISCUSS] We must change the way we review PIPs

[Yu]

+1 for allowing collaborators to review, comment, approve, or request
further changes more conveniently

On Fri, Mar 31, 2023 at 11:26 AM Nitin Goyal 
wrote:

> +1 (non-binding)
>
> On Fri, 31 Mar, 2023, 08:41 Jun Ma,  wrote:
>
> > +1.
> >
> > Besides using a single source to lift the review efficiency, adding
> > control over the design documents is also a good practice from the
> project
> > management perspective.
> >
> >
> > Best,
> > Jun
> > 
> > From: Yunze Xu 
> > Sent: Friday, March 31, 2023 10:44
> > To: dev@pulsar.apache.org 
> > Subject: Re: [DISCUSS] We must change the way we review PIPs
> >
> > +1 to me. Once the discussion thread of a PIP became too long, it
> > would be hard to continue the discussion.
> >
> > Thanks,
> > Yunze
> >
> > On Fri, Mar 31, 2023 at 9:13 AM PengHui Li  wrote:
> > >
> > > +1 for creating a folder named "pip" in the main pulsar repo
> > > So far, it is good enough to solve the problems we've had.
> > >
> > > If it is really worth moving to another repo in the future.
> > > We can move it maybe 3, 5 years later.
> > >
> > > Thanks,
> > > Penghui
> > >
> > >
> > > On Fri, Mar 31, 2023 at 8:29 AM tison  wrote:
> > >
> > > > Hi Asaf,
> > > >
> > > > Thanks for starting this thread!
> > > >
> > > > I have similar thoughts on using a single source for reviewing PIPs.
> > GH PRs
> > > > are good for conversation, although multiple conversations are still
> > hard
> > > > to follow (which can be natural)
> > > >
> > > > Here is how Rust does it[1] - a self-documented RFC repo + review
> PRs +
> > > > tracking issue on the main repo once accepted.
> > > >
> > > > Here is what I designed for TiDB[2][3]; proposals are placed in a
> > folder
> > > > under the main repo.
> > > >
> > > > We don't have to follow other community's ways, but these two
> practices
> > > > seem good to read.
> > > >
> > > > And, to follow the ASF voting strategy[4][5], we may still need a
> > standard
> > > > vote mail thread and document the result on the mailing list.
> > > >
> > > > Best,
> > > > tison.
> > > >
> > > > [1] https://github.com/rust-lang/rfcs
> > > > [2] https://github.com/pingcap/tidb/tree/master/docs/design
> > > > [3]
> > > >
> > > >
> >
> https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/make-a-proposal.html
> > > > [4] https://www.apache.org/foundation/voting.html
> > > > [5] https://www.apache.org/dev/pmc.html#mailing-list-naming-policy
> > > >
> > > >
> > > > Girish Sharma  于2023年3月31日周五 04:33写道：
> > > >
> > > > > +1 (non-binding .. ? )
> > > > > I've already commented a couple of times (here and there) that the
> > > > process
> > > > > needs to be consolidated at a single place. This is a good and
> > detailed
> > > > > approach.
> > > > > Not sure if there is a historical context behind keeping the
> > discussion
> > > > in
> > > > > dev mailing list..
> > > > >
> > > > > Regards
> > > > >
> > > > > On Fri, Mar 31, 2023 at 1:57 AM Asaf Mesika  >
> > > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > In the last 2 months, I've increased my PIP review time (I do it
> in
> > > > > > cycles), and reviewed quite a few PIPs.
> > > > > >
> > > > > > My conclusion as a result of that:
> > > > > >
> > > > > > It's nearly impossible to review PIPs using a mailing list.
> > > > > > We must fix it soon.
> > > > > >
> > > > > > *Why?*
> > > > > > 1. Let's say you review the PIP and find 10 issues. Once you
> quote
> > and
> > > > > > comment on those ten points, you basically started 10 threads of
> > > > > > conversations.
> > > > > > After 2-3 ping pongs with quotes of quotes of quotes, it takes
> you
> > > > > forever
> > > > > > to read each thread properly. You find your CTRL-F to search to
> > find
> > > > your
> > > > > > original quote, and reply. Load it up again in your head,
> > switching to
> > > > > the
> > > > > > PIP tab to read it again.
> > > > > > After 10 ping pongs, it becomes almost an impossible mission.
> > > > > >
> > > > > > I can say I'm 75% tired just from the process, not from the
> review
> > > > > itself.
> > > > > >
> > > > > > 2. It's non collaborative by design.
> > > > > > After 10 ping pongs, the ability of someone to come and join the
> > > > > discussion
> > > > > > is 0. They need to go through so many replies, which are half
> > quotes,
> > > > > find
> > > > > > the original reply, and browse to the PIP.
> > > > > > It's no wonder people drop off the PIP review once we cross 5-6
> > > > replies.
> > > > > > It's no wonder, nobody joins after 10 replies.
> > > > > >
> > > > > > 3. It's not open to the public. Non collaborative.
> > > > > > You can't just get a link, and join the review. Not only because
> > of (1)
> > > > > and
> > > > > > (2). You need to join the mailing list. You don't get the past
> > emails
> > > > to
> > > > > > reply. Just joining the list is a high enough bar for many
> people.
> > > > > > I personally participated in review of proposals in OpenTelemetry
> > in
> > > > 

Re: [DISCUSS] PIP-261: Restructure Getting Started section

[Yu]

Hi Asaf,

Thanks for your great initiative!

To make the learning path accurate for all roles (beginners, developers,
operators) and give them what they need in minimal viable docs, I would
suggest making changes to information architecture, like creating 3 guides
(subpages of https://pulsar.apache.org/docs) for 3 roles respectively.

I've explained in detail with examples here [1], PTAL. Thank you！

[1] https://github.com/apache/pulsar/issues/19912#issuecomment-1489677523

On Thu, Mar 30, 2023 at 1:04 AM Asaf Mesika  wrote:

> I have only one reviewer so far.
> Would appreciate 2 more PMC members eyes on this.
>
> Thanks!
>
> Asaf
>
> > On 23 Mar 2023, at 17:48, Asaf Mesika  wrote:
> >
> > Hi,
> >
> > In light of PIP-98, I would like to present sub-PIP to restructure the
> Getting Started Section.
> >
> > https://github.com/apache/pulsar/issues/19912
> >
> >
> > The goal of this PIP is to describe how we want the Table Of Contents of
> the Getting Started section to look like. Using the TOC we’ll be able to
> rebuild this section to make it very easy to get started with Pulsar.
> >
> >
> > Would love to get your feedback on it.
> >
> >
> > Thanks!
> >
> > Asaf
> >
> >
>
>

Re: [RFR] Issue triaging contribution guide

[Yu]

Hi tison,

Thanks for raising this up! Just my $2:

==Guide Structure==

Suggest optimizing the guide structure with the EPPO and 5W2H methods to
clarify info and improve readability.

For example,

## What is issue triaging?
...

## Why is issue triaging beneficial?
...

## How to triage issues? (a step-by-step flow)
...

## References
### Label instructions
### Issue triage checklist
...

## Related topics
...

==Issue Labels Instructions==

To instruct users how to use issue labels, does it make sense to add
explanations for them?
Currently, we only have explanations for partial labels. [1].

The meaning of some labels is clear at 1st glance, while some are blur.

For example,

- `component/ML`
What does this mean?

- `lifecycle/stale`, `Stale`
What are the differences between them?
Now the issues labeled with them only show they haven't been updated for
some time, but no more action is taken next step. Can we define it?

-  `help wanted`
To help newbies find proper issues in minimal time, some communities use
"good-first-issuse" while others use "help wanted". We can clarify this
explicitly.

==New Issue Labels==

Does it make sense to create new labels like "priority" or "severity"?

For example, p0, p1, p2; s0, s1, s2.

The pros (help identify and solve urgent or severe issues quickly) outweigh
the cons (increase complexity a little).

==Lean Toward Closing==

For the cases that can close issues, can we add more applicable scenarios
to reduce triagers "guilties"? (since we cannot satisfy all users and need
to keep the project maintainable)

==Re-Evaluating Closed Issues==

Does it make sense to add some instructions for this?

This happens at intervals because decisions might be adjusted based on
additional info that surfaces later.

==Visuals==

Suggest creating illustrations [2] to give users a holistic and bird-eye
view of the whole workflow. A picture is worth a thousand words.

==

Yu

[1] https://pulsar.apache.org/contribute/develop-labels/
[2]
https://equiptowerhamlets.nhs.uk/wp-content/uploads/2020/06/Triage-process-overview.jpg


On Tue, Mar 28, 2023 at 5:20 PM tison  wrote:

> Hi,
>
> I squashed over 1000 stale issues and PRs in Dec. 2022. During the work, I
> notice that the community may lack some written guides for issue triaging,
> and even if a contributor is willing to help, he/she doesn't know what to
> do but just leave it as is.
>
> I wrote a draft for this case[1]. It encourages contributors to do basic
> classification and encourages committers to close issues as not planned
> when it's the case.
>
> Moving forward a valid issue requires knowledge and time, but by sharing &
> aligning issue triage patterns, we can reduce a few engineering loss.
>
> Best,
> tison.
>
> [1] https://github.com/apache/pulsar-site/pull/485
>

Re: [Discuss] PIP-256: Building Great Developer Experience with API Content

[Yu]

Hi Asaf,

Thanks for your explanations! Now I understand your point.

I've summarized the doc issues, solutions, corresponding changes, task
status, and more here [1].
Also, add the link to the issue. PTAL, TIA!

[1]
https://docs.google.com/document/d/1NWmfDyIyUGzXOqX8V28AHyORF72lTFIvxlM6n86wAfU/edit?pli=1#bookmark=id.6soebl1lbvj0

On Sun, Mar 19, 2023 at 9:43 PM Asaf Mesika  wrote:

> I'll rephrase what I mean.
>
> Why I finish reading https://github.com/apache/pulsar/issues/19755, I
> should be able to answer the following questions, *without* resorting to
> reading external links (i.e. Google Doc):
>
> 1. What exactly is problematic with current API docs?
> List concisely a bullet point list of problems. For example:
> - REST API docs are missing parameters and their description.
> - There are no examples per endpoint
> - There aren't any tutorials for those who like to learn by doing compared
> with by reading.
> - There is no DevOps path and Dev path: a TOC page for developers and a TOC
> page for DevOps (TOC = Table of Content)
> ...
>
> 2. What are the exact changes we plan to make to improve the API docs?
> A list of specific changes, usually in the form of a table of contents and
> for each section listing a small description of what it will contain.
>
> Right now when you read the PIP, you can't answer those questions above.
>
>
>
> On Thu, Mar 16, 2023 at 2:14 PM Yu  wrote:
>
> > Hi Asaf, thanks for your questions! Please see my response below.
> >
> > 
> >
> > > 1. What are the exact problems we have?
> >
> > As stated in the Motivation, there were several issues in previous docs
> > (2.11.x and earlier versions). The biggest one was " many contents are
> > missing".
> >
> > Previously, Pulsar admin API content had nothing but the "reference" [1].
> > It shows only brief descriptions, commands, and flags and does not
> contain
> > context (Who/What/Why/When/Where/How), guides, tutorials, examples,
> demos,
> > etc.
> >
> > > The "who/what/" is too vague.
> >
> > "Who" means who is the primary target audience of Pulsar API content.
> I've
> > analyzed various personas and described them in "Pulsar API users" [2].
> >
> > "What" means the deliverables that we need to create for different users
> at
> > different stages, which are designed based on the following factors:
> > - User knowledge level (dev levels)
> > - User journey stage (discover and research → evaluate → get started →
> > implement and troubleshoot → celebrate → maintain)
> > - User needs (what are their goals?)
> > - Learning habits (where do they look for info)
> > - Learning path  (how do they learn?)
> > ...
> >
> > I've explained them in "Pulsar user journey stages and API content" [3].
> >
> > 
> >
> > > 2. What exactly do we plan to change?
> >
> > Actually, we (+@hangc0276) have made significant doc changes based on
> this
> > idea. Click this [4] to check out the new docs.
> >
> > 
> >
> > [1] "Reference" refers to
> > - REST API reference:
> > https://pulsar.apache.org/admin-rest-api/?version=2.11.0
> > - Java admin API reference: https://pulsar.apache.org/api/admin/2.11.x/
> > - pulsar-admin reference:
> > https://pulsar.apache.org/reference/#/2.11.x/pulsar-admin → This should
> > not
> > be on the "Pulsar admin API" guide but it was.
> >
> > [2]
> >
> >
> https://docs.google.com/document/d/1NWmfDyIyUGzXOqX8V28AHyORF72lTFIvxlM6n86wAfU/edit?pli=1#bookmark=kix.2ttjjn5z1ovo
> >
> > [3]
> >
> >
> https://docs.google.com/document/d/1NWmfDyIyUGzXOqX8V28AHyORF72lTFIvxlM6n86wAfU/edit?pli=1#bookmark=id.xgnk69nwtqi
> >
> > [4] https://lists.apache.org/thread/d7w276y70230onczqkodhskg38kjpl8d
> >
> > On Wed, Mar 15, 2023 at 9:43 PM Asaf Mesika 
> wrote:
> >
> > > I read the PIP but I can't understand the following:
> > >
> > > 1. What are the exact problems we have?
> > > I can say for example that a concrete issue is that the parameters for
> > the
> > > rest API endpoints are not documented at all. (see getStats
> > > <https://pulsar.apache.org/docs/2.11.x/admin-api-topics/#get-stats> )
> > > It's really hard to understand both from the document and PIP itself
> the
> > > problems. The "who/what/" is too vague.
> > >
> > > 2. What exactly do we pla

Re: New Pulsar docs (API + CLI) are available!

[Yu]

Thank you, Max and Asaf!

> One small note: https://pulsar.apache.org/docs/next/admin-api-tutorial/ -
I didn't find a tutorial there, mainly setup instructions.

Yes, this is a known issue, which will be optimized later.


On Sun, Mar 19, 2023 at 9:51 PM Asaf Mesika  wrote:

> Good work - this makes the API documentation better for end users and less
> confusing.
>
> One small note: https://pulsar.apache.org/docs/next/admin-api-tutorial/ -
> I
> didn't find a tutorial there, mainly setup instructions.
>
>
> On Fri, Mar 17, 2023 at 11:13 AM Max Xu  wrote:
>
> > Yu , Thanks for driving this. It looks great!
> >
> > Best,
> > Max Xu
> >
> >
> > On Thu, Mar 16, 2023 at 8:06 PM Yu  wrote:
> >
> > > Hi community,
> > >
> > > To improve the developer experience and take Pulsar content to the next
> > > level, recently we (+@hangc0276) have added some new docs as below.
> > >
> > > ===
> > > Fresh New Content
> > > ===
> > >
> > > - Pulsar API
> > > (https://pulsar.apache.org/docs/next/pulsar-api-overview/)
> > >
> > > - Pulsar admin API
> > > → Overview (https://pulsar.apache.org/docs/next/admin-api-overview/)
> > > → Use cases (https://pulsar.apache.org/docs/next/admin-api-use-cases/）
> > > → Features (https://pulsar.apache.org/docs/next/admin-api-features/)
> > > → Tools (https://pulsar.apache.org/docs/next/admin-api-tools/)
> > > → Get started (
> > https://pulsar.apache.org/docs/next/admin-api-get-started/)
> > >
> > > - Pulsar client API
> > > (https://pulsar.apache.org/docs/next/client-api-overview/)
> > >
> > > - Pulsar CLI
> > > → pulsar-admin: Get started (
> > > https://pulsar.apache.org/docs/next/get-started-pulsar-admin/)
> > >
> > > Enjoy reading!
> > > Here [1] are related doc PRs.
> > > We'll add more docs on these topics in the near future.
> > > Feel free to leave your suggestions, TIA!
> > >
> > > ===
> > > Acknowledgment
> > > ===
> > >
> > > @hangc0276 Huge shout out to you for providing technical input and
> > > guidance!
> > >
> > > @BewareMyPower @horizonzy A big thank you for your technical support!
> > >
> > > ===
> > >
> > > [1]
> > > - https://github.com/apache/pulsar-site/pull/462
> > > - https://github.com/apache/pulsar-site/pull/403
> > > - https://github.com/apache/pulsar/pull/19002
> > > - https://github.com/apache/pulsar/pull/18680
> > >
> > > Yu
> > >
> >
>

Re: [Discuss] PIP-256: Building Great Developer Experience with API Content

[Yu]

Hi Asaf, thanks for your questions! Please see my response below.



> 1. What are the exact problems we have?

As stated in the Motivation, there were several issues in previous docs
(2.11.x and earlier versions). The biggest one was " many contents are
missing".

Previously, Pulsar admin API content had nothing but the "reference" [1].
It shows only brief descriptions, commands, and flags and does not contain
context (Who/What/Why/When/Where/How), guides, tutorials, examples, demos,
etc.

> The "who/what/" is too vague.

"Who" means who is the primary target audience of Pulsar API content. I've
analyzed various personas and described them in "Pulsar API users" [2].

"What" means the deliverables that we need to create for different users at
different stages, which are designed based on the following factors:
- User knowledge level (dev levels)
- User journey stage (discover and research → evaluate → get started →
implement and troubleshoot → celebrate → maintain)
- User needs (what are their goals?)
- Learning habits (where do they look for info)
- Learning path  (how do they learn?)
...

I've explained them in "Pulsar user journey stages and API content" [3].



> 2. What exactly do we plan to change?

Actually, we (+@hangc0276) have made significant doc changes based on this
idea. Click this [4] to check out the new docs.



[1] "Reference" refers to
- REST API reference:
https://pulsar.apache.org/admin-rest-api/?version=2.11.0
- Java admin API reference: https://pulsar.apache.org/api/admin/2.11.x/
- pulsar-admin reference:
https://pulsar.apache.org/reference/#/2.11.x/pulsar-admin → This should not
be on the "Pulsar admin API" guide but it was.

[2]
https://docs.google.com/document/d/1NWmfDyIyUGzXOqX8V28AHyORF72lTFIvxlM6n86wAfU/edit?pli=1#bookmark=kix.2ttjjn5z1ovo

[3]
https://docs.google.com/document/d/1NWmfDyIyUGzXOqX8V28AHyORF72lTFIvxlM6n86wAfU/edit?pli=1#bookmark=id.xgnk69nwtqi

[4] https://lists.apache.org/thread/d7w276y70230onczqkodhskg38kjpl8d

On Wed, Mar 15, 2023 at 9:43 PM Asaf Mesika  wrote:

> I read the PIP but I can't understand the following:
>
> 1. What are the exact problems we have?
> I can say for example that a concrete issue is that the parameters for the
> rest API endpoints are not documented at all. (see getStats
> <https://pulsar.apache.org/docs/2.11.x/admin-api-topics/#get-stats> )
> It's really hard to understand both from the document and PIP itself the
> problems. The "who/what/" is too vague.
>
> 2. What exactly do we plan to change?
>
> I couldn't understand what we plan to change, *practically*.
>
> I would expect something like:
> * The table of content would look like this... and mention the TOC and
> explain briefly each section.
> * Each endpoint would be documented as such: and supply a template/example
> for one.
>
>
>
>
> On Wed, Mar 15, 2023 at 9:30 AM Yu  wrote:
>
> > Hi Dave and tison, thanks for your feedback!
> >
> > I've added the required info and explanations to the PIP issue [1]
> > concisely.
> >
> > Feel free to take a look and leave your suggestions. TIA!
> >
> > [1] https://github.com/apache/pulsar/issues/19755
> >
> > Yu
> >
> > On Wed, Mar 15, 2023 at 11:11 AM tison  wrote:
> >
> > > Hi Yu,
> > >
> > > Thanks for starting this thread!
> > >
> > > Perhaps you can reorganize the content in PIP template form so that we
> > > known the background and what is proposed at first. I read the doc and
> > the
> > > changes proposed are at the last six pages (Changing the Admin API docs
> > > information architecture). The previous 40 pages look like a survey to
> be
> > > referred to, instead of the proposal itself.
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > Dave Fisher  于2023年3月15日周三 10:38写道：
> > >
> > > > Hi Yu,
> > > >
> > > > Your first document is really website analytics which should be
> shared
> > > > with the community which might have different conclusions. It would
> be
> > > > helpful in understanding motivation. I feel it needs to be in an
> issue
> > as
> > > > markdown where it is easy to review. I’ll note that it is dated from
> > July
> > > > 2022.
> > > >
> > > > The second document is the real PIP. Please share the detail in a
> > > friendly
> > > > way in a PIP issue.
> > > >
> > > > This is an important effort and I’m sure that the communit

New Pulsar docs (API + CLI) are available!

[Yu]

Hi community,

To improve the developer experience and take Pulsar content to the next
level, recently we (+@hangc0276) have added some new docs as below.

===
Fresh New Content
===

- Pulsar API
(https://pulsar.apache.org/docs/next/pulsar-api-overview/)

- Pulsar admin API
→ Overview (https://pulsar.apache.org/docs/next/admin-api-overview/)
→ Use cases (https://pulsar.apache.org/docs/next/admin-api-use-cases/）
→ Features (https://pulsar.apache.org/docs/next/admin-api-features/)
→ Tools (https://pulsar.apache.org/docs/next/admin-api-tools/)
→ Get started (https://pulsar.apache.org/docs/next/admin-api-get-started/)

- Pulsar client API
(https://pulsar.apache.org/docs/next/client-api-overview/)

- Pulsar CLI
→ pulsar-admin: Get started (
https://pulsar.apache.org/docs/next/get-started-pulsar-admin/)

Enjoy reading!
Here [1] are related doc PRs.
We'll add more docs on these topics in the near future.
Feel free to leave your suggestions, TIA!

===
Acknowledgment
===

@hangc0276 Huge shout out to you for providing technical input and guidance!

@BewareMyPower @horizonzy A big thank you for your technical support!

===

[1]
- https://github.com/apache/pulsar-site/pull/462
- https://github.com/apache/pulsar-site/pull/403
- https://github.com/apache/pulsar/pull/19002
- https://github.com/apache/pulsar/pull/18680

Yu

Re: [Discuss] PIP-256: Building Great Developer Experience with API Content

[Yu]

Hi Dave and tison, thanks for your feedback!

I've added the required info and explanations to the PIP issue [1]
concisely.

Feel free to take a look and leave your suggestions. TIA!

[1] https://github.com/apache/pulsar/issues/19755

Yu

On Wed, Mar 15, 2023 at 11:11 AM tison  wrote:

> Hi Yu,
>
> Thanks for starting this thread!
>
> Perhaps you can reorganize the content in PIP template form so that we
> known the background and what is proposed at first. I read the doc and the
> changes proposed are at the last six pages (Changing the Admin API docs
> information architecture). The previous 40 pages look like a survey to be
> referred to, instead of the proposal itself.
>
> Best,
> tison.
>
>
> Dave Fisher  于2023年3月15日周三 10:38写道：
>
> > Hi Yu,
> >
> > Your first document is really website analytics which should be shared
> > with the community which might have different conclusions. It would be
> > helpful in understanding motivation. I feel it needs to be in an issue as
> > markdown where it is easy to review. I’ll note that it is dated from July
> > 2022.
> >
> > The second document is the real PIP. Please share the detail in a
> friendly
> > way in a PIP issue.
> >
> > This is an important effort and I’m sure that the community will want to
> > easily suggest improvements. Doing this in an issue or even an email
> thread
> > would really help.
> >
> > Best,
> > Dave
> >
> > Sent from my iPhone
> >
> > > On Mar 14, 2023, at 6:38 PM, Yu  wrote:
> > >
> > > Hi Asaf, thanks for your reminder!
> > >
> > > The corresponding issue was filed at
> > > https://github.com/apache/pulsar/issues/19755 previously.
> > >
> > > Since it's a large initiative containing many content and complex
> > formats,
> > > I've made it in Google Docs first and will relocate them to the issue
> > once
> > > it's accepted by the community.
> > >
> > >> On Wed, Mar 15, 2023 at 12:08 AM Asaf Mesika 
> > wrote:
> > >>
> > >> Side note: PIP should be in markdown in a GitHub issue for prosperity.
> > >> External links lose permissions over time, come and go.
> > >>
> > >>
> > >>
> > >>> On Mon, Mar 13, 2023 at 6:00 PM Yu  wrote:
> > >>>
> > >>> Hi community,
> > >>>
> > >>> Based on the [2022 Report] Pulsar Website Content Analysis (GA) [1],
> > the
> > >>> Pulsar API doc is one of the top-viewed content. However, Pulsar API
> > was
> > >>> not systematically and logically explained previously.
> > >>>
> > >>> To address this issue, I've created a content strategy and designed
> the
> > >>> information architecture for Pulsar API content in *PIP-256: Building
> > >> Great
> > >>> Developer Experience with API Content* [2], which explains:
> > >>>
> > >>> - What is API content?
> > >>> - Why does API content matter?
> > >>> - How to design API content?
> > >>>- Design thinking
> > >>>- Design process
> > >>> - Deliverables, implement timeline and progress
> > >>> ...
> > >>>
> > >>> Feel free to share your thoughts on this proposal, TIA!
> > >>>
> > >>> [1]
> > >>>
> > >>>
> > >>
> >
> https://docs.google.com/document/d/1H-wEEfut18M18dle6a4-2EWCnLOqyJ81RVYxkPkTXhk/edit
> > >>> [2]
> > >>>
> > >>>
> > >>
> >
> https://docs.google.com/document/d/1NWmfDyIyUGzXOqX8V28AHyORF72lTFIvxlM6n86wAfU/edit?pli=1#bookmark=id.xgnk69nwtqi
> > >>>
> > >>> Yu
> > >>>
> > >>
> >
> >
>

Re: Re: Introducer Pulsar admin api to pulsar-client-go

[Yu]

Hi Eric,

Thanks for sharing the updates!

I discussed this project with Max previously. We would like to contribute
docs for it, and I've already added "Go admin API (coming soon)" to the new
Pulsar API docs already [1], which brings many benefits, such as:

- Build excitement before launch.
- Generate a targeted list of early adopters interested in this brand-new
tool.
- Improve SEO by adding relevant keywords.

[1] https://github.com/apache/pulsar-site/pull/462#discussion_r1130770643

Yu


On Wed, Mar 15, 2023 at 11:56 AM Shen Eric 
wrote:

> Hi Zhangjian,
>
> We can share some progress on our side:
>
> we have completed:
>
>   *   Extracted the pulsar-admin-go library from the pulsarctl and moved
> it to a separate repo under StreamNative (now it is private)
>   *   Updated the project layout and rename some pkg names like the cli pkg
>
> what we will do next:
>
>   *   Add some pulsar-admin-go library documentation
>   *   Setup some CI/CD infra configurations for the repo
>   *   Then we will release the 0.1.0 and open source this repo
>
> The release of the 0.1.0 and repo open-source we wanna make it in March
> and will announce this to the community.
>
> The timeline to donate this project to Apache is undecided now but we will
> listen to the feedback from the community and donate it when most of us
> think it's qualified and stable.
>
> On 2023/03/03 04:14:33 ZhangJian He wrote:
> > Hi, Eric. Thank you very much for the work you have done. I have no
> > objections to the process, and it would be even better if there could be
> a
> > rough timeline.
> >
> > Thanks
> > ZhangJian He
> >
> >
> > On Fri, 3 Mar 2023 at 09:06, Shen Eric  wrote:
> >
> > > Hi Zhangjian,
> > >
> > > I am a PM from StreamNative and we also had some internal discussions
> > > related to this topic. Let me share our ongoing planning:
> > >
> > > * We will extract the pulsar admin pkg from the pulsarctl to a
> > > separate open repo which will be called pulsar-admin-go under
> StreamNative.
> > > * Will iterate the pulsar-admin-go library by adding more tests,
> > > documentation and may also update or fix the existing APIs.
> > > * After the pulsar-admin-go library is stable, we will contribute this
> > > project to Apache Foundation.
> > >
> > > Do you think this plan works for you?
> > >
> > > On 2023/02/17 01:47:26 ZhangJian He wrote:
> > > > I would like to express that the current Pulsar client for Go
> > > > (pulsar-client-go) is missing the pulsar Admin API. As such, I would
> like
> > > > to propose that we work towards adding this feature to
> pulsar-client-go.
> > > >
> > > > I believe that this new feature would be a valuable addition to
> > > > pulsar-client-go, and I am excited to work to make it happen.
> > > >
> > > > I have submitted a PR:
> > > https://github.com/apache/pulsar-client-go/pull/959
> > > > The full api is not currently available, but we are adding.
> > > >
> > > > Below is a simple example about how to use
> > > >
> > > > ## usage
> > > >
> > > > ```go
> > > > package main
> > > >
> > > > import (
> > > > "fmt"
> > > > "github.com/apache/pulsar-client-go/padmin"
> > > > )
> > > >
> > > > func main() {
> > > > admin, err := padmin.NewDefaultPulsarAdmin()
> > > > if err != nil {
> > > > panic(err)
> > > > }
> > > > // get namespace topic list
> > > > topics, err := admin.PersistentTopics.ListNamespaceTopics("tenant",
> > > > "namespace")
> > > > if err != nil {
> > > > panic(err)
> > > > }
> > > > fmt.Println(topics)
> > > > }
> > > > ```
> > > >
> > > > Thanks
> > > > ZhangJian He
> > > >
> > >
> > >
> > > --
> > >
> > > Best regards,
> > >
> > > Eric Shen 沈瑀昊
> > >
> >
>
>
> --
>
> Best regards,
>
> Eric Shen 沈瑀昊
>

Re: [VOTE] PIP-249: Pulsar website redesign

[Yu]

+1
Thanks, Asaf and Emidio!
The new copywriting and visuals are fantastic!

On Wed, Mar 15, 2023 at 4:56 AM Dave Fisher  wrote:

> +1(binding)
>
> Please fix the following sentence: “ Pulsar, although released to Apache
> in 2017 (and actually built in 2012), ” it is not correct. Pulsar code was
> donated to the Apache Software Foundation via a Software Grant in 2017 (and
> initially created in 2012)
>
> Best,
> Dave
>
> Sent from my iPhone
>
> > On Mar 14, 2023, at 8:58 AM, Sijie Guo  wrote:
> >
> > +1 (binding)
> >
> >> On Tue, Mar 14, 2023 at 8:43 AM Matteo Merli 
> wrote:
> >>
> >> +1 (binding)
> >>
> >>
> >> --
> >> Matteo Merli
> >> 
> >>
> >>
> >>> On Tue, Mar 14, 2023 at 8:29 AM Asaf Mesika 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I would like to start the vote on PIP-249: Pulsar website redesign.
> >>>
> >>> PIP link: https://github.com/apache/pulsar/issues/19611
> >>>
> >>> You can read the discussion thread here:
> >>> https://lists.apache.org/thread/3of7dfhn4qk033hqlqpvbc8so6bcolz4
> >>>
> >>> Thanks,
> >>>
> >>> Asaf
> >>>
> >>
>

Re: [Discuss] PIP-256: Building Great Developer Experience with API Content

[Yu]

Hi Asaf, thanks for your reminder!

The corresponding issue was filed at
https://github.com/apache/pulsar/issues/19755 previously.

Since it's a large initiative containing many content and complex formats,
I've made it in Google Docs first and will relocate them to the issue once
it's accepted by the community.

On Wed, Mar 15, 2023 at 12:08 AM Asaf Mesika  wrote:

> Side note: PIP should be in markdown in a GitHub issue for prosperity.
> External links lose permissions over time, come and go.
>
>
>
> On Mon, Mar 13, 2023 at 6:00 PM Yu  wrote:
>
> > Hi community,
> >
> > Based on the [2022 Report] Pulsar Website Content Analysis (GA) [1], the
> > Pulsar API doc is one of the top-viewed content. However, Pulsar API was
> > not systematically and logically explained previously.
> >
> > To address this issue, I've created a content strategy and designed the
> > information architecture for Pulsar API content in *PIP-256: Building
> Great
> > Developer Experience with API Content* [2], which explains:
> >
> > - What is API content?
> > - Why does API content matter?
> > - How to design API content?
> > - Design thinking
> > - Design process
> > - Deliverables, implement timeline and progress
> > ...
> >
> > Feel free to share your thoughts on this proposal, TIA!
> >
> > [1]
> >
> >
> https://docs.google.com/document/d/1H-wEEfut18M18dle6a4-2EWCnLOqyJ81RVYxkPkTXhk/edit
> > [2]
> >
> >
> https://docs.google.com/document/d/1NWmfDyIyUGzXOqX8V28AHyORF72lTFIvxlM6n86wAfU/edit?pli=1#bookmark=id.xgnk69nwtqi
> >
> > Yu
> >
>

[Discuss] PIP-256: Building Great Developer Experience with API Content

[Yu]

Hi community,

Based on the [2022 Report] Pulsar Website Content Analysis (GA) [1], the
Pulsar API doc is one of the top-viewed content. However, Pulsar API was
not systematically and logically explained previously.

To address this issue, I've created a content strategy and designed the
information architecture for Pulsar API content in *PIP-256: Building Great
Developer Experience with API Content* [2], which explains:

- What is API content?
- Why does API content matter?
- How to design API content?
- Design thinking
- Design process
- Deliverables, implement timeline and progress
...

Feel free to share your thoughts on this proposal, TIA!

[1]
https://docs.google.com/document/d/1H-wEEfut18M18dle6a4-2EWCnLOqyJ81RVYxkPkTXhk/edit
[2]
https://docs.google.com/document/d/1NWmfDyIyUGzXOqX8V28AHyORF72lTFIvxlM6n86wAfU/edit?pli=1#bookmark=id.xgnk69nwtqi

Yu

Re: [DISCUSS] PMC/Committer Emiratus status

[Yu]

Hi Asaf,

Thanks for bringing this up!

If I may put my two pennies' worth:

To be honest, this idea flashed across my mind previously. I talked about
this to my colleague, and he was surprised that I was willing to be
deprived of benefits (at that time, I was a PMC member already).

PMC members are vital promotors and driving forces of a community. Ideally,
they should be direction leaders and make great contributions
*continuously*. No one should enjoy the benefits of honor but not
contribute much *all the time*. Setting retirement bars for PMC members
reminds us to contribute and provide value. Maybe I'm a little aggressive
:-)

~~

+1 but a long list of PMC members with many inactive members does not
create a good feeling since "false prosperity" is no better than "real
contributions".

> 3. Merit doesn’t expire.

~~

Compared to my previous thought, Goetz has proposed a better idea since:

1. It's mild and can be accepted by many PMC members. A kind of life wisdom
:-)

2. People who need help (e.g., PIP approvals / PR comments / ...) from PMC
members can check the flags to know who is available to help.

Except for flags, I suggest adding "area of expertise" for PMC members and
committers, so people will know who are the most suitable experts to ask
for help or collaborate.

> 1. You can maintain active/inactive status at the project level with a
simple flag on a community page, without removing people from the PMC.
> 2. By making it an informal, self-reported flag, you avoid the overhead
of board resolutions, etc. and just manage it at the community level. If
someone wants to change their status, they can just say so or submit a pull
request to change their status on the pulsar website.

~~

Yu

On Sun, Mar 5, 2023 at 10:31 PM Asaf Mesika  wrote:

> Thanks to everyone who took the time to carefully answer with detailed
> explanations.
> I personally learned a lot about Apache projects this way (made me read
> about it some more).
>
> So my personal recap is:
>
>- The goal of knowing the health of the Apache Pulsar community can be
>achieved by taking a look at monthly active contributors over time
>displayed on the community page.
>   - It could be nice getting those numbers on the mailing list itself
>   as well.
>- Calculating the engagement is not an easy task.
>- Kicking people off is not something you'd like to do in general and
>specifically for volunteers.
>- People's credit for work, which is also expressed in PMC membership
>never expires due to Merit never expires - your work credit and earned
>right should not expire.
>
>
> I personally see PMC members answering someone not a PMC member nor a
> comitter on this topic as a very healthy community indicator :)
>
> Thanks !
>
> Asaf
>
> On Fri, Mar 3, 2023 at 10:22 AM Enrico Olivelli 
> wrote:
>
> > This is an interesting discussion.
> > Good to see this kind of a discussion on the dev@ mailing list, this
> > way more people are aware of the fact that we are a project in the ASF
> > and there is a Project Management Committee.
> >
> > I have been following a few Apache projects for a while, and I believe
> > that this kind of discussions should be run on the private@ mailing
> > list.
> > It is the PMC that usually deals with this stuff.
> >
> > As Tison said, the common practice is that you never remove anyone
> > from a PMC or from the Committers list.
> >
> > This happens only in rare cases where an individual behaves in such a
> > way that the Project or the Foundation could be damaged,
> > for instance if you speak on behalf of the project and you offend
> > someone publicly.
> >
> > Inactive contributors/committers/PMC members do not do any harm to a
> > project.
> >
> > Some projects have some rules that you cannot participate in official
> > VOTEs if you are not "active".
> >
> > If anyone has some problems with someone in the community, then they
> > can reach out to priv...@pulsar.apache.org and the PMC will listen to
> > the problem and take actions.
> >
> > my 2 cents
> >
> > Enrico
> >
> > Il giorno ven 3 mar 2023 alle ore 04:39 Yunze Xu
> >  ha scritto:
> > >
> > > As a PMC member, I don't like playing a game of determining who should
> > > be removed from PMC as well.
> > >
> > > I hear a viewpoint that someone is only participating in the community
> > > only to join a PMC so that he can benefit from it. After becoming a
> > > PMC member, he is never active in the community. It might be true but
> > > I think it's acceptable. Making such a rule won't prevent such 

Re: [DISCUSS] PIP-249: Pulsar website redesign

[Yu]

Hi @asafm and @emidio-cardeira thanks for your great work!

You've contributed new designs (with colors/elements/... that have not been
used) for Pulsar, which is a big step for the community.

Preiviously we've collected some rules at Pulsar Design Style Guide [1],
which are used to create illustrations in docs.

If this new look is accepted, can you document the design rules/best
practice? They should be available in the Contribution Guide [2].

In this way, other contributors can follow and create designs in high
quality and consistent style.

Thanks!

~

[1]
https://docs.google.com/document/d/16Hp7Sc86MQtL0m8fc2w_TrcKXAuglwRwHmdmwfk00mI/edit#heading=h.b8ogodj5sj

[2] https://pulsar.apache.org/contribute/


On Fri, Feb 24, 2023 at 5:27 AM Asaf Mesika  wrote:

> Hi,
>
> PIP issue: https://github.com/apache/pulsar/issues/19611
>
> One of the key elements that attracted me to Pulsar was how awesome it is -
> built in 2012 yet fits the new strategy of being cloud-native - simply
> incredible. It's not only that - it has so many outstanding features,
> making it a cutting edge, modern powerhouse in the messaging system
> category.
>
> Yet, its site does not reflect that.
> It does the opposite.
> People new to Pulsar, not knowing it as we do in the community, would think
> it's an old, unmaintained technology, and maybe not even bother reading the
> landing page.
>
> This is why I embarked on a journey to improve Pulsar web-site, in bite
> sizes. My first step was improving the landing page copy for the elevator
> pitch, opening paragraph, and the feature descriptions (In this PR
> )
>
> Today, together with my friend, co-worker and designer Emidio, I would like
> to propose the second step: revamp the landing page structure and most
> importantly - the website look and feel.
>
> The PIP  contains:
> * The screenshots for it
> * A "live" Figma view for it
> * Detailed explanation of what was changed and why.
>
> I think you'll love it.
>
> Happy to hear your thoughts.
>
>
> Asaf Mesika
>

Re: Modern look for the website

[Yu]

Hi @visortelle thank you very much for your awsome job! This is a great
addition to the Pulsar website!

I've checked the design and left my comments at
https://github.com/apache/pulsar-site/pull/426#issuecomment-1436220520.

Also request more reviews from relevant stakeholders.

On Mon, Feb 20, 2023 at 6:38 AM Kiryl Valkovich 
wrote:

> Hi everyone!
>
>
>
> I don't think anyone will argue, it’s important to have a fresh-looking
> website to attract new users.
>
>
>
> I decided to try to refresh it a little bit.
>
>
>
> Over the weekend I managed to make a home page. I think that I can finish
> other pages in 1-2 weeks, depending on my workload.
>
>
>
> Current version: https://pulsar.apache.org/
>
> New version: https://pulsar-site-three.vercel.app
>
>
>
> Draft PR: https://github.com/apache/pulsar-site/pull/426
>
>
>
> After the redesign, I plan to add a few more pages.
>
>
>
> Should I continue?
>
>

[DISSCUSS] Support getStats/update partitioned topic with `-partition-`

[Ruguo Yu]

Hello community,

 

### Motivation

Same as [19230](https://github.com/apache/pulsar/pull/19230), We allow users to 
use the `Client API` to create the partitioned topic which name contains 
`-partition-{not-number}` when `allowAutoTopicCreation` is `true` and 
`allowAutoTopicCreationType` is `partitioned` in configuration, such as topic 
`persistent://my-tenant/my-namespace/my-topic-partition-abc`. 

However we didn't get stats and update it because related method will strictly 
verify whether the topic's name contains keyword `partition` on the server 
side, which will lead to the impassability of such topics.

 

### Modifications

Support getting stats and updating partitioned topics with the keyword 
`-partition-{not-number}` in PR[0].

 

Best,

Ruguo Yu

 

[0] https://github.com/apache/pulsar/pull/19235

Announcing Pulsar Virtual Summit Europe 2023: CFP Is Now Open!

[Yu]

Hi community,

We're excited to announce Pulsar Virtual Summit Europe 2023 is happening on
May 23rd! Join us at the Summit by submitting your session here [1].

Since 2020, seven global Pulsar Summit events have featured 170+
interactive sessions by experts from Google, AWS, Splunk, Tencent, Verizon
Media, Iterable, Yahoo, Nutanix, and more. The conferences have garnered
2,200 attendees representing 700 companies. Now, we're bringing Pulsar
Summit back to the virtual stage in Europe for more engaging and insightful
sessions.

Get all the current details for the Summit here [2], and stay tuned for
more to come!

# Want to share your Pulsar story?

Submit your session idea and join us at the Summit! Sharing your experience
and expertise is a great way to raise your profile in the rapidly growing
Apache Pulsar community. All sessions will be pre-recorded, and anyone can
submit an idea regardless of location.

# CFP Deadline: March 3, 2023

# Become a Community Sponsor (no fee required)

Grow brand awareness and increase your company’s profile by being a
Community Sponsor for Pulsar Virtual Summit Europe 2023! Learn more about
the free sponsorship opportunity [3].

>>>>>>>>>>

[1]
https://sessionize.com/pulsar-virtual-summit-europe-2023/?utm_campaign=Pulsar%20Virtual%20Summit%20Europe%202023_source=hs_email_medium=email&_hsenc=p2ANqtz--0FfE3xVne3TMv5zwhWMZqigqyif8UrRmTW3xR2z-kySrD2AVPxmSJvWHj-5m5wH6eoXnX

[2]
https://streamnative.io/blog/announcing-pulsar-virtual-summit-europe-2023-cfp-is-now-open?utm_campaign=Pulsar%20Virtual%20Summit%20Europe%202023_source=hs_email_medium=email&_hsenc=p2ANqtz--0FfE3xVne3TMv5zwhWMZqigqyif8UrRmTW3xR2z-kySrD2AVPxmSJvWHj-5m5wH6eoXnX

[3]
https://6585952.fs1.hubspotusercontent-na1.net/hubfs/6585952/Sponsorship%20Prospectus%20Pulsar%20Virtual%20Summit%20Europe%202023.pdf?utm_campaign=Pulsar%20Virtual%20Summit%20Europe%202023_source=hs_email_medium=email&_hsenc=p2ANqtz--0FfE3xVne3TMv5zwhWMZqigqyif8UrRmTW3xR2z-kySrD2AVPxmSJvWHj-5m5wH6eoXnX

>>>>>>>>>>

Yu

Re: [ANNOUNCE] Nicolò Boschi as new PMC member in Apache Pulsar

[Yu]

Congrats Nico!

On Mon, Jan 23, 2023 at 10:47 PM Zixuan Liu  wrote:

> Congrats, Nicolò!
>
> Best,
> Zixuan
>
> Dave Fisher  于2023年1月21日周六 06:01写道：
>
> > Congratulations Nicolo!
> >
> > Best,
> > Dave
> >
> > > On Jan 20, 2023, at 6:57 AM, tison  wrote:
> > >
> > > Congrats Nico! And well deserved :)
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > Christophe Bornet  于2023年1月20日周五 22:39写道：
> > >
> > >> Congrats, Nicolo !
> > >>
> > >> Le ven. 20 janv. 2023 à 14:27, Enrico Olivelli 
> a
> > >> écrit :
> > >>
> > >>> Congratulations !
> > >>>
> > >>> Enrico
> > >>>
> > >>> Il giorno ven 20 gen 2023 alle ore 13:36 Lari Hotari
> > >>>  ha scritto:
> > 
> >  Dear Community,
> > 
> >  We are thrilled to announce that Nicolò Boschi
> >  (https://github.com/nicoloboschi) has been invited and has accepted
> > >> the
> >  role of member of the Apache Pulsar Project Management Committee
> > (PMC).
> > 
> >  Nicolò Boschi has been a vital asset to our community, consistently
> >  demonstrating his dedication and active participation through
> >  significant contributions such as the development of the Pulsar
> Shell
> >  and numerous bug fixes, security enhancements, and improvements to
> >  Pulsar and its CI pipeline. In addition to his technical
> > contributions,
> >  Nicolò also plays an important role in reviewing pull requests and
> >  ensuring the overall quality of our project. We look forward to his
> >  continued contributions.
> > 
> >  On behalf of the Pulsar PMC, we extend a warm welcome and
> >  congratulations to Nicolò Boschi.
> > 
> >  Best regards, Lari, on behalf of the Pulsar PMC
> > >>>
> > >>
> >
> >
>

RE: Re: [DISCUSS] Add unified newTableView method in PulsarClient

[Ruguo Yu]

Sorry,I forgot to paste the corresponding PR: 
https://github.com/apache/pulsar/pull/19048

I have fixed the typo in above PR.

 

On 2023/01/16 02:10:07 PengHui Li wrote:

> +1

> 

> And It might be a typo when adding the table view APIs

> From the example:

> 

> https://github.com/apache/pulsar/blob/246c2701e5c43e02e9783c82d4d107d06b019951/pulsar-client-api/src/main/java/org/apache/pulsar/client/api/PulsarClient.java#L232-L238

> 

> And from the proposal, the method name is newTableView()

> 

> https://github.com/apache/pulsar/issues/12356

> 

> Thanks,

> Penghui

> 

> On Sun, Jan 15, 2023 at 6:31 PM Ruguo Yu  wrote:

> 

> > Hi Community,

> >

> > Currently, we can use PulsarClient to create `Producer`, `Consumer`,

> > `Reader` and `TableView`, releated method as below:

> >

> > ```

> >

> > ProducerBuilder newProducer();

> >

> >  ProducerBuilder newProducer(Schema schema);

> >

> > ConsumerBuilder newConsumer();

> >

> >  ConsumerBuilder newConsumer(Schema schema);

> >

> > ReaderBuilder newReader();

> >

> >  ReaderBuilder newReader(Schema schema);

> >

> >  TableViewBuilder newTableViewBuilder(Schema schema);

> >

> > ```

> >

> > However, it is obvious that the method of creating `TableView` is not

> > consistent with other methods, and no method with default scheme is

> > provided.

> >

> >

> >

> > ### Motivation

> >

> > Add unified `newTableView(Schema)` method and replace

> > `newTableViewBuilder(Schema)`(attach `@Deprecated` annotation to it) in

> > PulsarClient, which could consistent with `newProducer(Schema)`,

> > `newConsumer(Schema)`, `newReader(Schema)`.

> >

> > In addition, we will provide `newTableView()` method which  has default

> > schema.

> >

> >

> >

> > ### Modifications

> >

> > 1. Add `newTableView(Schema)` method and replace

> > `newTableViewBuilder(Schema)`(attach `@Deprecated` annotation to it)  in

> > PulsarClient

> >

> > 2. Add `newTableView()` method and Scheme default is `Schema.BYTES` in

> > PulsarClient

> >

> >

> >

> > Thanks

> >

> > Ruguo Yu

> >

> >

> 

 

 

[DISCUSS] Add unified newTableView method in PulsarClient

[Ruguo Yu]

Hi Community,

Currently, we can use PulsarClient to create `Producer`, `Consumer`, `Reader` 
and `TableView`, releated method as below:

```

ProducerBuilder newProducer();

 ProducerBuilder newProducer(Schema schema);

ConsumerBuilder newConsumer();

 ConsumerBuilder newConsumer(Schema schema);

ReaderBuilder newReader();

 ReaderBuilder newReader(Schema schema);

 TableViewBuilder newTableViewBuilder(Schema schema);

```

However, it is obvious that the method of creating `TableView` is not 
consistent with other methods, and no method with default scheme is provided.

 

### Motivation

Add unified `newTableView(Schema)` method and replace 
`newTableViewBuilder(Schema)`(attach `@Deprecated` annotation to it) in 
PulsarClient, which could consistent with `newProducer(Schema)`, 
`newConsumer(Schema)`, `newReader(Schema)`.

In addition, we will provide `newTableView()` method which  has default schema.

 

### Modifications

1. Add `newTableView(Schema)` method and replace 
`newTableViewBuilder(Schema)`(attach `@Deprecated` annotation to it)  in 
PulsarClient

2. Add `newTableView()` method and Scheme default is `Schema.BYTES` in 
PulsarClient

 

Thanks

Ruguo Yu

RE: [ANNOUNCE] Yunze Xu as a new PMC member in Apache Pulsar

[Ruguo Yu]

Congratulations, Yunze!

On 2022/12/29 12:42:36 Haiting Jiang wrote:
> Hi all,
> 
> The Apache Pulsar Project Management Committee (PMC) has invited Yunze Xu
> (https://github.com/BewareMyPower) as a member of the PMC and we are
> pleased to announce that he has accepted.
> 
> He is very active in the community in the past few years and made a lot of 
> great contributions.
> 
> Welcome Yunze to the Apache Pulsar PMC.
> 
> Best Regards,
> Haiting Jiang on behalf of the Pulsar PMC
>

Re: [ATTENTION] The source of Pulsar document is moved to apache/pulsar-site

[Yu Liu]

Thanks, tison and Michael!

I've added one workflow that needs to be updated as Michael talked about
the PR template [1]

https://github.com/apache/pulsar/issues/19111#issuecomment-1370596495

On Wed, Jan 4, 2023 at 1:34 PM Michael Marshall 
wrote:

> > I'd prefer not to put too many things in the template.
>
> I agree with this sentiment. I think the template is already too busy.
> Many active contributors ignore important sections leaving them with
> the default text.
>
> However, I think a link pointing to where to contribute documentation
> would help new contributors. We could also point contributors to the
> contribution guide.
>
> I recently contributed to kedacore/keda and they had a concise
> template that was intuitive and had several links [0].
>
> Thanks,
> Michael
>
> [0]
> https://raw.githubusercontent.com/kedacore/keda/main/.github/PULL_REQUEST_TEMPLATE.md
>
> On Tue, Jan 3, 2023 at 11:23 PM tison  wrote:
> >
> > Thanks for your feedback!
> >
> > Michael:
> >
> > I've updated the "Edit this page" link to jump to the site repo and the
> > Documentation guide should properly describe the process. Do you find
> some
> > incorrect content in the PR template? Otherwise, I'd prefer not to put
> too
> > many things in the template.
> >
> > Best,
> > tison.
> >
> >
> > Michael Marshall  于2023年1月4日周三 13:09写道：
> >
> > > Thanks for all of your work on this!
> > >
> > > One follow up is that we should update the PR template [0] so that
> > > contributors know where to contribute documentation.
> > >
> > > Thanks,
> > > Michael
> > >
> > > [0]
> > >
> https://github.com/apache/pulsar/blob/9ec1d071c7188a2db694e9d7b359faaf33cb076e/.github/PULL_REQUEST_TEMPLATE.md
> > >
> > > On Tue, Jan 3, 2023 at 8:29 PM Yu  wrote:
> > > >
> > > > Hi tison, thanks for your great work!
> > > >
> > > > On Fri, Dec 30, 2022 at 6:41 PM tison  wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > With the resolution of [1], I moved the source of the Pulsar
> document
> > > to
> > > > > the site repo[2][3][4][5].
> > > > >
> > > > > Now, if you'd like to update Pulsar document, you should submit a
> PR
> > > > > against the site repo (apache/pulsar-site) instead of the main repo
> > > > > (apache/pulsar, the site2 folder).
> > > > >
> > > > > I've updated the Edit URL on the page[6], so if you click the "Edit
> > > this
> > > > > page" button, you will be guided to the correct place.
> > > > >
> > > > > The docs layout is almost the same as former site2 folder. I'll
> update
> > > the
> > > > > corresponding contribution guide and release guide later. You can
> keep
> > > an
> > > > > eye on the tracking issue[7].
> > > > >
> > > > > Best,
> > > > > tison.
> > > > >
> > > > > [1]
> https://lists.apache.org/thread/89wl112cflvtoyfg3l7kglr1dozsljm9
> > > > > [2] https://github.com/apache/pulsar-site
> > > > > [3] https://github.com/apache/pulsar/pull/19100
> > > > > [4] https://github.com/apache/pulsar-site/pull/348
> > > > > [5] https://github.com/apache/pulsar/issues/19090
> > > > > [6]
> > > > >
> > > > >
> > >
> https://github.com/apache/pulsar-site/commit/a2c2d23c21fd9cf936a4381901001b5889973d8e
> > > > > [7] https://github.com/apache/pulsar/issues/19064
> > > > >
> > >
>

Re: [ATTENTION] The source of Pulsar document is moved to apache/pulsar-site

[Yu]

Hi tison, thanks for your great work!

On Fri, Dec 30, 2022 at 6:41 PM tison  wrote:

> Hi,
>
> With the resolution of [1], I moved the source of the Pulsar document to
> the site repo[2][3][4][5].
>
> Now, if you'd like to update Pulsar document, you should submit a PR
> against the site repo (apache/pulsar-site) instead of the main repo
> (apache/pulsar, the site2 folder).
>
> I've updated the Edit URL on the page[6], so if you click the "Edit this
> page" button, you will be guided to the correct place.
>
> The docs layout is almost the same as former site2 folder. I'll update the
> corresponding contribution guide and release guide later. You can keep an
> eye on the tracking issue[7].
>
> Best,
> tison.
>
> [1] https://lists.apache.org/thread/89wl112cflvtoyfg3l7kglr1dozsljm9
> [2] https://github.com/apache/pulsar-site
> [3] https://github.com/apache/pulsar/pull/19100
> [4] https://github.com/apache/pulsar-site/pull/348
> [5] https://github.com/apache/pulsar/issues/19090
> [6]
>
> https://github.com/apache/pulsar-site/commit/a2c2d23c21fd9cf936a4381901001b5889973d8e
> [7] https://github.com/apache/pulsar/issues/19064
>

Re: [PROPOSAL] Website precommit and move the source of docs to the site repo

[Yu]

Thanks tison!

It's better to
a) update the contribution processes of docs, website content, and release
notes [1] [2] [3] [4] [5]
b) inform the community about this breaking change officially in another
email (reminders for doc contributions)



docs:
[1] https://pulsar.apache.org/contribute/document-contribution/
[2]
https://pulsar.apache.org/contribute/document-preview/#preview-documentation-changes
[3]
https://pulsar.apache.org/contribute/document-preview/#preview-website-changes

release notes:
[4] https://pulsar.apache.org/contribute/release-process/#update-the-site
[5] https://pulsar.apache.org/contribute/release-note-guide/

On Thu, Dec 29, 2022 at 9:07 PM tison  wrote:

> The new repo is reduced by 100MB:
>
> $ gh repo clone apache/pulsar -- --single-branch --depth=1
> $ du -sh pulsar | sort -rh
>  53M pulsar
>
> Best,
> tison.
>
>
> tison  于2022年12月29日周四 21:01写道：
>
> > Landed.
> >
> > Best,
> > tison.
> >
> >
> > tison  于2022年12月29日周四 17:51写道：
> >
> >> Here are the related PRs:
> >>
> >> * https://github.com/apache/pulsar/pull/19100
> >> * https://github.com/apache/pulsar-site/pull/348
> >>
> >> Best,
> >> tison.
> >>
> >>
> >> tison  于2022年12月26日周一 21:45写道：
> >>
> >>> FYI tracking issue has been created:
> >>> https://github.com/apache/pulsar/issues/19064
> >>>
> >>> I plan to finish it by the end of next month.
> >>>
> >>> Best,
> >>> tison.
> >>>
> >>>
> >>> tison  于2022年12月21日周三 11:33写道：
> >>>
> >>>> Thanks for your feedback!
> >>>>
> >>>> @Yu
> >>>>
> >>>> Thanks for sharing the previous thread. I looped in @michaeljmarshall
> >>>> here.
> >>>>
> >>>> @Jun
> >>>>
> >>>> It's possible but causes a new shortcoming: Now you should tell the
> >>>> contributor that the versioned docs are different from the NEXT
> version
> >>>> docs, lol.
> >>>>
> >>>> If our developers don't complain about these separated sources. Like
> @Asaf
> >>>> comment:
> >>>>
> >>>> > We can take, let's say, five features and see if they were actually
> >>>> done in
> >>>> > the same PR or separate PR. I guess that most documentation is
> >>>> actually
> >>>> > updated separately. Thus, from that perspective, maybe it’s not a
> con.
> >>>>
> >>>> Then we can do this refactor thoroughgoing.
> >>>>
> >>>> Also, if we keep, somehow several sources in the main repo. We still
> >>>> have shortcomings:
> >>>>
> >>>> 1. Duplicated CI workflows.
> >>>> 2. Cumbersome preview scaffolding in the main repo.
> >>>>
> >>>> ... which is the original purpose I'd like to overcome.
> >>>>
> >>>> Best,
> >>>> tison.
> >>>>
> >>>>
> >>>> Jun Ma  于2022年12月21日周三 11:19写道：
> >>>>
> >>>>> Is it possible to come up with a compromised solution that has the
> >>>>> pros of both sides but minimizes the side effect? I'm thinking maybe
> it's
> >>>>> not necessary to sacrifice the current contribution process, as long
> as it
> >>>>> can greatly reduce the load of back-end actions and source size. For
> >>>>> example, if we only move out the versioned docs to the site repo but
> keep
> >>>>> the source of the NEXT docs in the pulsar repo, does this help to
> win a
> >>>>> large proportion of those pros when people can still contribute as
> usual?
> >>>>>
> >>>>> 
> >>>>> From: Jiaqi Shen 
> >>>>> Sent: Tuesday, December 20, 2022 17:15
> >>>>> To: dev@pulsar.apache.org 
> >>>>> Subject: Re: [PROPOSAL] Website precommit and move the source of docs
> >>>>> to the site repo
> >>>>>
> >>>>> +1, it makes sense to me.
> >>>>>
> >>>>> Thanks,
> >>>>> Jiaqi Shen
> >>>>>
> >>>>>
> >>>>> Yu  于2022年12月19日周一 20:57写道：
> >>>>>
> >>>>> > Hi tison,
> >>>>> >
> >>&

Re: [ANNOUNCE] Yunze Xu as a new PMC member in Apache Pulsar

[Yu]

Congrats! Yunze

On Thu, Dec 29, 2022 at 11:00 PM Zike Yang  wrote:

> Congratulations! Yunze
>
> BR.
> Zike Yang
>
> On Thu, Dec 29, 2022 at 10:42 PM Zixuan Liu  wrote:
> >
> > Congrats! Yunze
> >
> > Best,
> > Zixuan
> >
> > oliver.shen...@gmail.com  于2022年12月29日周四
> 22:34写道：
> >
> > >
>

Re: [VOTE] PIP-228: Refactor the information architecture of Pulsar client docs

[Yu]

+1

On Tue, Dec 20, 2022 at 3:12 PM Yunze Xu 
wrote:

> +1 (non-binding)
>
> Thanks,
> Yunze
>
> On Tue, Dec 20, 2022 at 3:06 PM Zike Yang  wrote:
> >
> > +1 (non-binding)
> >
> > Thanks,
> > Zike Yang
> >
> > On Tue, Dec 13, 2022 at 4:38 PM Jun Ma  wrote:
> > >
> > > Hi all,
> > >
> > > I'm going to start the vote for PIP-228 [Refactor the information
> architecture of Pulsar client docs](
> https://github.com/apache/pulsar/issues/18822).
> > >
> > > And this is the original thread for discussion:
> https://lists.apache.org/thread/bv6lwnt708dxst173knyzv2bfy4d1ox4.
> > >
> > > The vote will be open for at least three days.
> > >
> > >
> > > Thank you.
> > > Jun
>

Re: [PROPOSAL] Website precommit and move the source of docs to the site repo

[Yu]

Hi tison,

Thanks for raising this up!

Our community had a similar discussion previously and chose to "keep" the
doc repo stay in the Pulsar main repo at that time.

[1] lists the pros and cons of "keep" and "not keep" solutions.

I'm +0 on this proposal because I think the total scores of these two
solutions are almost equal after weighing the pros and cons.



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


On Mon, Dec 19, 2022 at 5:40 PM tison  wrote:

> Thanks for your feedback!
>
> @Asaf
>
> > pre-commit
>
> I mean CI checks before merging a patch. Currently, we don't run checks for
> the content before merging them. This causes a series of syntax errors and
> broken links issues. If we hold docs under site2 folder in the main repo
> and then copied to the site repo, we have two places to build such CI
> checks. What's worse, the checks for the main repo will be quite
> cumbersome (that you do some if-else logic in the whole Pulsar CI
> workflows, and do the sync sequentially in that workflow).
>
> If we hold the source of docs only in the site repo, we can extend the
> "precommit" workflow[1] I added recently to check for syntax errors and
> broken links also.
>
> > What does the apache/pulsar-site repo contain today?
>
> It should be covered by the documentation guide page[2]. It holds the
> source of the official website and the user docs are synced from the main
> repo.
>
> > What content do we have today in the pulsar repo related to the site?
>
> After issue-18014[3] is done, we host only user docs and some JSON metadata
> in the main repo, which is synced by site_syncer.py[4].
>
> > Can you explain that better? Are you saying pulsar source JARs contain
> the documentation?
>
> No. Source JARs contain only the Java files and necessary copyrights info.
> The source release is, for example,
>
> https://archive.apache.org/dist/pulsar/pulsar-2.10.2/apache-pulsar-2.10.2-src.tar.gz
> ,
> which is extracted to 173M where 129M is occupied by the site2 folder.
>
> This also affects when developers do git clone to clone the repo.
>
> > I mean, if you wish to document a bug fix in 2.9.x, for example, would
> you do it in the 2.9.x branch under site2/docs or
> site2/website/versioned_docs/2.9.5?
>
> This is another question. Ideally, we should have hosted versioned docs
> associated with the specific version to that branch, like Apache Flink does
> as I mentioned[5]. But we do not, and actually the situation is we update
> the versioned docs under the master branch and thus, the docs can be synced
> properly.
>
> See also the "Alternatives" section in the original email.
>
> @All
>
> Since we don't have objections to the possible cons listed above or any new
> ones, I'm going to create a tracking issue later this week and show what
> will be changed in PRs for further review.
>
> Best,
> tison.
>
> [1]
>
> https://github.com/apache/pulsar-site/blob/f7abc615d57d9846ed093922d24bff952dc0e838/.github/workflows/ci-precommit.yml
> [2]
>
> https://pulsar.apache.org/contribute/document-contribution/#source-repositories
> [3] https://github.com/apache/pulsar/issues/18014
> [4]
>
> https://github.com/apache/pulsar-site/blob/f7abc615d57d9846ed093922d24bff952dc0e838/tools/pytools/lib/execute/site_syncer.py
> [5] https://github.com/apache/flink/tree/master/docs
>
>
> PengHui Li  于2022年12月19日周一 16:26写道：
>
> > +1
> >
> > I support moving them to the website repo.
> >
> > Thanks,
> > Penghui
> >
> > On Mon, Dec 19, 2022 at 12:04 PM Yunze Xu 
> > wrote:
> >
> > > +1. The most significant point to me is that we can preview all the
> > > content of the website without synchronizing contents from the
> > > apache/pulsar repo.
> > >
> > > Thanks,
> > > Yunze
> > >
> > > On Mon, Dec 19, 2022 at 9:53 AM Li Li  wrote:
> > > >
> > > > +1, That’s a good idea.
> > > >
> > > > > On Dec 16, 2022, at 07:07, tison  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > After several works around the build flow of our official
> > > website[1][2][3],
> > > > > the content sync and site build flow is debuggable and reproducible
> > > now.
> > > > >
> > > > > However, compared to other Apache projects' websites' project
> layouts
> > > and
> > > > > workflow, we still meet two challenges on the Pulsar site:
> > > > >
> > > > > 1. We don't have a pre-commit workflow for any website-related
> > changes.
> > > > > Thus, we don't detect broken links or syntax errors when reviewing
> > new
> > > > > patches[4][5][6].
> > > > > 2. The website's content is two-level down in `site2/website-next`
> > for
> > > > > historical reasons, which is confusing for contributors.
> > > > >
> > > > > To overcome these two shortcomings, I propose the following:
> > > > >
> > > > > 1. Move the website's content to the root level, then we have a
> > > first-class
> > > > > Docu JS project layout. It's more convenient and
> familiar
> > to
> > > > > related developers.
> > > > > 2. Host the source of docs in the site repo 

Re: Too many emails - Is there a better way to control or manage emails from GitBox

[Yu]

Hi tison,

Thanks for clearing up various issues and PRs!

One quick question:
For the "Discussion posts" converted from "Issues", can we set it not to
sync to dev@pulsar.apache.org (since they do not have new discussions and
comments)?

Thank you!


On Mon, Dec 12, 2022 at 10:30 AM Zili Chen  wrote:

> In the Kvrocks community, we meet the same problem and redirect the mails
> to issues@[1].
>
> Although, three points here:
>
> 1. Follow the ASF policy all effective discussions should happen on the
> mailing list, while to issues@ should be also "on the list".
> 2. For personal mailbox, you can set up a filter.
> 3. For https://lists.apache.org/ searching, you may use `-GITBOX' but it
> can filter unexpected mails.
>
> Best,
> tison.
>
> [1] https://github.com/apache/incubator-kvrocks/pull/1023
>
> On 2022/12/09 11:45:44 Girish Sharma wrote:
> > Hello Pulsar community,
> >
> > I recently joined this ML. I have been keenly following the RC, Voting
> and
> > PIP related email threads so far. I only have one question - is there a
> way
> > to disable the emails from GitBox about github discussions? Mainly for
> the
> > following reasons:
> >
> >1. The GitHub discussions emails from GitBox do not thread properly as
> >the subject of the email contains unique text like "XYZ commented on
> thread
> >"
> >2. There is already a way to subscribe to github discussions via
> GitHub
> >UI so these emails are duplicated.
> >
> > Regards
> > --
> > Girish Sharma
> >
>

Happy Thanksgiving!

[Yu]

Hi team,

Today is the Thanksgiving Day. At this wonderful time of the year, I have
much to be immensely thankful for.

Everyone here has made this a truly global community and a terrific place
to collaborate.

Wish Pulsar continues to grow faster and stronger next year with our joint
efforts.

Happy Thanksgiving and have a great holiday season, wherever you are
located!

Yu

Re: Acknowledge contributors for each release

[Yu]

Hi tison,

Thanks for raising this up!

Expressing appreciation for contributors is a great way to improve health
and fitness in our community.

Here are just my two cents:

>>>>>>>>>>>>>>>>

1. Except for the all-contributors list, does it make sense and is it
possible to show the top 10 contributors for each release?

Here comes another issue, how to evaluate the top 10?

The simplest way is based on the lines of code (the same as how GitHub
counts contributions, etc), but it does not make sense to some degree.

At the same time, other factors (e.g. how active a contributor is, how many
PR/issues he/she reviews/answers, etc) can be taken into consideration, but
this might make things a little complicated. If we do not find a quick and
easy way to do this, it might overwhelm release managers.

>>>>>>>>>>>>>>>>

2. Does it make sense to show contributors for all Pulsar-related repos
(e.g. pulsar, pulsar-site, pulsar-client-cpp, pulsar-helm-chart) on the
Pulsar website?

SkyWalking follows this way, see "Contributors" at
https://skywalking.apache.org/team/.

>>>>>>>>>>>>>>>>

Feel free to correct me if am wrong, thank you!

Yu

On Mon, Nov 21, 2022 at 2:35 PM tison  wrote:

> Hi,
>
> Dave's email about first-time contributions reminds me of the idea to
> acknowledge contributors for each release.
>
> Let's see how the Flink community does it:
>
> For each release blog, e.g. [1], in the last section "List of
> Contributors",
> explicitly list out contributors and acknowledge their contributions.
>
> When it went back to the first time I got listed, I was proud to share it
> on social media and it encouraged me a lot to make more contributions.
> Also, from the community perspective, releasing patches as well as
> acknowledging the authors are somewhat fundamental rewards we can offer.
>
> To generate the list, I adapt the scripts provided by Flink as:
>
> 1. For Pulsar v2.10.0 (minor version release):
>
>   git log --pretty="%an%n%cn" v2.9.0..v2.10.0 | sort | uniq | tr "\n" "," |
> sed 's/,/, /g'
>
> ... which gives:
>
> Addison Higham, Ali Ahmed, Aloys, Amar Prakash Pandey, Andras Beni, Andrey
> Yegorov, AnonHxy, Anonymitaet, Arnar, Baozi, Bharani Chadalavada, Bowen Li,
> Boyang Jerry Peng, Callum Duffy, Christophe Bornet, Da Xiang Huang, Dave
> Fisher, David Kjerrumgaard, Devin Bost, Dezhi LIiu, Dianjin Wang, Diego,
> Enrico Olivelli, Eric Shen, Eron Wright, Fangbin Sun, Frank J Kelly,
> Frederic Kneier, Gautier DI FOLCO, GitHub, Haaroon Y, Hang Chen,
> HuangQiang, Huanli Meng, Jagadesh Adireddi, Jason918, JiangHaiting, Jin,
> Jiwei Guo, Kai, Kai Wang, Koen Rutten, Lakshmi Balu, Lari Hotari, Lars
> Hvam, Lei Zhiyuan, Li Li, Lishen Yao, Marvin Cai, Masahiro Sakamoto,
> Massimiliano Mirelli, Matt Fleming, Matteo Merli, Md Mostafijur Rahman,
> Michael Marshall, Neng Lu, Nicklee007, Nicolò Boschi, Ofek Lev, Paul Gier,
> Peter Tinti, Qiang Huang, Qiang Zhao, Rajan Dhabalia, Roc Marshal, Ruguo
> Yu, Rui Fu, Saumitra Srivastav, Shen Liu, Sijie Guo, Smile, TakaHiro, Tao
> Jiuming, Thomas Leplus, Tong, Travis Sturzl, Vincent Royer, WangJialing,
> Xiangying Meng, Xiaobing Fang, Xiaoyu Hou, YANGLiiN, Yan, Yang Yang,
> Yannick Koechlin, Yong Zhang, Yunze Xu, Yuri Mizushima, Yuto Furuta, Zach
> Walsh, ZhangJian He, Zhanpeng Wu, Zhiwu Wang, Zike Yang, Zixuan Liu, Ziyao
> Wei, aarondonwilliams, baomingyu, bentonliang, billowqiu, chenlin,
> codertmy, congbo, entvex, fengtao1998, feynmanlin, fu-turer, gaozhangmin,
> goflutterjava, hanmz, hrsakai, imryao, junqingzh, kaushik-develop,
> kijanowski, kimula takesi, lightzhao, lin chen, lipenghui, litao,
> liuchangqing, liudezhi, madhavan-narayanan, ming, mingyifei, momo-jun,
> penghui, ran, sijia-w, suiyuzeng, wenbingshen, xiaolong ran, youzipi,
> zhaoyajun2009, 包子, 萧易客
>
> 2. For Pulsar v2.10.1 (patch version release):
>
>   git log --pretty="%an%n%cn" v2.10.0..v2.10.1 | sort | uniq | tr "\n" ","
> | sed 's/,/, /g'
>
> ... which gives:
>
> Adrian Paul, AlvaroStream, Andrey Yegorov, Baodi Shi, Baozi, Christophe
> Bornet, Cong Zhao, Dezhi LIiu, Enrico Olivelli, GitHub, JiangHaiting, Jim
> Baugh, Jiwei Guo, Kai Wang, Kay Johansen, Lari Hotari, LinChen, Lishen Yao,
> Matt-Esch, Matteo Merli, Michael Marshall, Neng Lu, Nicolò Boschi, Qiang
> Huang, Qiang Zhao, Ruguo Yu, Rui Fu, Shen Liu, Tao Jiuming, Tian Luo,
> WangJialing, Xiangying Meng, Xiaoyu Hou, Yan Zhao, Yang Yang, Yong Zhang,
> Yunze Xu, Yuri Mizushima, ZhangJian He, Zike Yang, Zixuan Liu, boatrainlsz,
> codertmy, congbo, dependabot[bot], fengyubiao, gaoran10, gaozhangmin,
> grayson, lin chen, lipenghui, lixinyang, llIlll, penghui, ran, wuxuanqicn,
> 赵延,
>
> I think we can integrate such a step into the release process[2] if we
> reach a consensus. But let me start this thread first to see your thoughts
> and suggestions.
>
> Looking forward to your feedback!
>
> Best,
> tison.
>
> [1] https://flink.apache.org/news/2022/10/28/1.16-announcement.html
> [2] https://pulsar.apache.org/contribute/release-process
>

RE: [ANNOUNCE] New Committer: Zili Chen

[Ruguo Yu]

Congratulations! tison

 

Ruguo Yu

 

On 2022/11/10 00:15:22 Yu wrote:

> The Project Management Committee (PMC) for Apache Pulsar has invited Zili

> Chen (https://github.com/tisonkun)

> to become a committer and we are pleased to announce that he has accepted.

> 

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

> 

> Welcome and congratulations, Zili Chen!

> 

> Please join us in congratulating and welcoming Zili Chen onboard!

> 

> Best Regards,

> Yu on behalf of the Pulsar PMC

> 

 

 

[ANNOUNCE] New Committer: Zili Chen

[Yu]

The Project Management Committee (PMC) for Apache Pulsar has invited Zili
Chen (https://github.com/tisonkun)
to become a committer and we are pleased to announce that he has accepted.

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.

Welcome and congratulations, Zili Chen!

Please join us in congratulating and welcoming Zili Chen onboard!

Best Regards,
Yu on behalf of the Pulsar PMC

Re: [VOTE] PIP-212: Default reppDnsResolverClass to ZkBookieRackAffinityMapping

[Yu]

Thanks, Michael!
Feel free to ping me if you need a doc review.

On Tue, Oct 25, 2022 at 2:17 AM Michael Marshall 
wrote:

> +1 (binding)
>
> Thank you all for voting.
>
> I am closing the vote with 4 binding +1 votes (Dave, Enrico, PengHui,
> Michael) and 2 non-binding +1 votes (Bo, Zike).
>
> I will merge and cherry-pick the changes, and I'll make sure all
> documentation is updated.
>
> Thanks,
> Michael
>
>
> On Sun, Oct 23, 2022 at 8:49 PM Zike Yang  wrote:
> >
> > +1 (non-binding)
> >
> > Thanks,
> > Zike Yang
> >
> > On Mon, Oct 24, 2022 at 9:37 AM PengHui Li  wrote:
> > >
> > > +1 (binding)
> > >
> > > Thanks,
> > > Penghui
> > >
> > > On Sat, Oct 22, 2022 at 4:03 AM Dave Fisher  wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > > On Oct 20, 2022, at 11:06 PM, Michael Marshall <
> mmarsh...@apache.org>
> > > > wrote:
> > > > >
> > > > > Bump. In my opinion, this is a bug that we need to fix before any
> new
> > > > > releases. It is only a PIP because fixing the bug requires
> updating a
> > > > > default.
> > > > >
> > > > > Thanks,
> > > > > Michael
> > > > >
> > > > > On Fri, Oct 14, 2022 at 1:58 PM Michael Marshall <
> mmarsh...@apache.org>
> > > > wrote:
> > > > >>
> > > > >> Hi All,
> > > > >>
> > > > >> I am starting the vote for PIP 212: Default reppDnsResolverClass
> to
> > > > >> ZkBookieRackAffinityMapping.
> > > > >> https://github.com/apache/pulsar/issues/18012
> > > > >>
> > > > >> Here is the discussion thread:
> > > > >> https://lists.apache.org/thread/188nq3vcs40cwdwj5z2jon0ryfqh3wbg
> > > > >>
> > > > >> The vote will be open for at least 3 days.
> > > > >>
> > > > >> Note that just before sending this email, I sent a note to the
> > > > >> discussion thread classifying the current configuration as a bug
> and
> > > > >> indicating that I will cherry pick this change to all active
> release
> > > > >> branches, assuming it is accepted.
> > > > >>
> > > > >> Thanks,
> > > > >> Michael
> > > >
> > > >
>

Doc Contribution Guides are available in Pulsar repos!

[Yu]

Hi community,

Recently, I've submitted the following doc contribution guides to the
Pulsar GitHub repos [1].

They provide a set of guides offering best-practice suggestions for
contributing documentation to Pulsar with detailed instructions on the
contribution workflow and conventions.

Please follow these guidelines to keep the documentation structure, style,
and syntax consistent.

>>>>>>>>>>>>

# Before writing docs
- Pulsar Documentation Contribution Guide
- Doc structure and project organization
- Workflow of submitting various docs

# Writing docs
- Pulsar Documentation Writing Syntax Guide
- Pulsar Documentation Writing Style Guide
- Pulsar Design Style Guide
- Pulsar API Documentation Guide

# Testing docs
- Pulsar Content Preview Guide

# Preparing to submit doc PRs
- Pulsar Pull Request Naming Convention Guide
- Pulsar Documentation Label Guide

# Other
- Pulsar Release Note Guide [2]

[1] https://github.com/apache/pulsar/tree/master/site2
[2]
https://github.com/apache/pulsar/blob/master/wiki/release/release-note-guide.md

>>>>>>>>>>>>

Feel free to comment if you have any suggestions or concerns.

Many thanks for your technical guidance! @urfreespace,
@signormercurio, @tisonkun, @nodece

Yu

Re: [DISCUSS] Archive Ancient (Incubating) Documents

[Yu]

Hi tison,

Thanks for taking care of the docs!
Seems that archiving the incubating docs does not affect the existing
workflow of Pulsar doc update/maintenance.
+1 for this proposal.

Yu

On Mon, Oct 17, 2022 at 3:24 PM tison  wrote:

> Hi folks,
>
> I noticed that we write a lot of logic to handle ancient documents back to
> the incubating period on the current doc site syncing and building. It
> causes unnecessary maintenance burdens as well as more broken links due to
> different document frameworks.
>
> Since those ancient documents have lower visits and most importantly, we
> should not make any changes to them, I propose:
>
> 1. Redirect https://pulsar.apache.org/docs/xxx-incubating/ to
> https://pulsar.staged.apache.org/docs/xxx-incubating
> 2. Remove
>
> https://github.com/apache/pulsar/tree/master/site2/website/versioned_docs/xxx-incubating
> .
> 3. Remove build logic about those pages.
>
> What do you think?
>
> Best,
> tison.
>

Pulsar Release Note Website and Guide

[Yu]

Hi community and release managers,

For the Pulsar Release Note website [1], here is some good news:

>>>>>>>>>>>>

# 1

We've simplified the workflow of submitting Pulsar release notes.

I've documented the workflow and everything about the Pulsar Release Note
website in the *Pulsar Release Note Guide* [2]. Please follow the steps
there.

>>>>>>>>>>>>

# 2

Now, the Pulsar Release Note website is generated automatically.

This great work is done by @signormercurio and @urfreespace! [4]

Huge THANKS to you!

>>>>>>>>>>>>

Feel free to comment if you have any questions or suggestions.

Yu

>>>>>>>>>>>>

[1] https://pulsar.apache.org/release-notes/

[2]
https://github.com/apache/pulsar/blob/master/wiki/release/release-note-guide.md

Note: the workflow of submitting release notes for C++ and Python clients
might be changed in recent days.

Context see
https://github.com/apache/pulsar/issues/17918#issuecomment-1273075920

[3] https://github.com/apache/pulsar/discussions/17310

Re: [DISCUSS] Decrease GitHub email notifications from apache/pulsar-* repos to this ML

[Yu]

+1, thank you, Michael!


On Wed, Oct 12, 2022 at 1:00 PM Matteo Merli  wrote:

> +1 Thanks Michael for fixing these!
>
>
>
> On Tue, Oct 11, 2022 at 9:52 PM Michael Marshall 
> wrote:
>
> > Hi All,
> >
> > I had a brief discussion with Matteo about mailing list notifications
> > for our apache/pulsar-* repos in this PR
> > https://github.com/apache/pulsar-client-cpp/pull/42. Please see it for
> > additional context.
> >
> > The outcome is a proposal to make all of our GitHub repos send their
> > notifications to commits@ instead of dev@. Contributors will be able
> > to subscribe to updates by using the GitHub "watch" feature.
> >
> > I created a sample PR here:
> > https://github.com/apache/pulsar-client-go/pull/861.
> >
> > If there are no major objections, I plan to move forward with the rest
> > of our repos later this week.
> >
> > Thanks,
> > Michael
> >
> --
> --
> Matteo Merli
> 
>

Re: [Discussion] Questions about the pulsar-site management

[Yu]

Hi Yunze,

Thanks for your feedback!

We (@SignorMercurio, @urfreespace) are implementing the idea of  "Pulsar
release page automation" [1] and updating the workflow [2].

I'll move the workflow to the pulsar/wiki/release folder [3] once it is
finalized.
And will move other documentation-related guides to the Contribution page
[4] later.

[1] https://github.com/apache/pulsar/discussions/17310
[2] https://github.com/apache/pulsar-site/pull/242#issuecomment-1272700632
[3] https://github.com/apache/pulsar/tree/master/wiki/release
[4] https://pulsar.apache.org/contributing/

Yu

On Tue, Oct 4, 2022 at 10:21 PM Yunze Xu 
wrote:

> TL; DR, we should add the Markdown documents about the pulsar-site repo
> in GitHub. DON'T USE GOOGLEDOCS EVERYWHERE!
>
> 
>
> Currently Pulsar's website is maintained in
> https://github.com/apache/pulsar-site. However, I cannot find any
> document of this document repo.
>
> As a contributor, if I want to contribute to this repo, I will look at
> the README first:
>
> https://github.com/apache/pulsar-site/blob/main/README.md
>
> However, I can barely find what I concerns about in it:
> - Where should I add the content
> - What should I do before opening a PR (e.g. building a preview)
> - How can I build a preview in my local env
> - How will the web page be updated due to the changes of this repo
>
> If I were a frontend engineer, I might also want to know how to
> develop the website for it.
>
> What I can find is:
>
> [Preview Website
> Changes](
> https://docs.google.com/document/d/1wszdtMRo6MhKbVaggPK7_bnKaC4TewuT--GWZZxJNGg/edit#heading=h.wu6ygjne8e35
> )
>
> from
> https://github.com/apache/pulsar-site/tree/main/site2/website-next.
>
> Yeah, I believe nobody will click into this directory if he cannot
> find anything from the README.md in the root directory.
>
> BTW, the details are in the external GoogleDocs link in
> https://github.com/apache/pulsar#documentation-1
>
> There is a terrible case recently:
>
> How to add the release note also changed after
> https://github.com/apache/pulsar-site/pull/227, we need to update them
> in JavaScript files. However, in
>
> https://github.com/apache/pulsar/blob/master/wiki/release/release-process.md#write-release-notes
> ,
> there is no update in [Pulsar Release Notes
> Guide](
> https://docs.google.com/document/d/1cwNkBefKyV6OPbEXnUrcCdVZi0i2BezqL6vAL7VqVC0/edit#
> ).
>
> If the release manager wants to know how to contribute the release
> notes, he might tend to find a previous PR like
> https://github.com/apache/pulsar-site/pull/209. Unfortunately, it's
> outdated. We have to update the `.js` files now, e.g.
> https://github.com/apache/pulsar-site/pull/242
>
> IMO, we should add a guidance into the pulsar-site repo. In addition,
> the documents should be maintained in GitHub as much as possible. It's
> better not just pasting an external GoogleDocs link. We can use
> GoogleDocs for the temporary changes, but we should present a stable
> Markdown document in GitHub.
>
> Thanks,
> Yunze
>
>
>
>
>

Re: Pulsar CI congested, master branch build broken

[Liu Yu]

Thanks Lari!

Does this issue cause the tests for PRs like 
https://github.com/apache/pulsar/pull/17198 to be hang?

On 2022/09/06 14:41:07 Dave Fisher wrote:
> We are going to need to take actions to fix our problems. See 
> https://issues.apache.org/jira/browse/INFRA-23633?focusedCommentId=17600749=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17600749
> 
> Jarek has done a large amount of GitHub Action work with Apache Airflow and 
> his suggestions might be helpful. One of his suggestions was Apache Yetus. I 
> think he means using the Maven plugins - 
> https://yetus.apache.org/documentation/0.14.0/yetus-maven-plugin/
> 
> 
> > On Sep 6, 2022, at 4:48 AM, Lari Hotari  wrote:
> > 
> > The Apache Infra ticket is 
> > https://issues.apache.org/jira/browse/INFRA-23633 . 
> > 
> > -Lari
> > 
> > On 2022/09/06 11:36:46 Lari Hotari wrote:
> >> I asked for an update on the Apache org GitHub Actions usage stats from 
> >> Gavin McDonald on the-asf slack in this thread: 
> >> https://the-asf.slack.com/archives/CBX4TSBQ8/p1662464113873539?thread_ts=1661512133.913279=CBX4TSBQ8
> >>  .
> >> 
> >> I hope we get this issue resolved since it delays PR processing a lot.
> >> 
> >> -Lari
> >> 
> >> On 2022/09/06 11:16:07 Lari Hotari wrote:
> >>> Pulsar CI continues to be congested, and the build queue [1] is very long 
> >>> at the moment. There are 147 build jobs in the queue and 16 jobs in 
> >>> progress at the moment.
> >>> 
> >>> I would strongly advice everyone to use "personal CI" to mitigate the 
> >>> issue of the long delay of CI feedback. You can simply open a PR to your 
> >>> own personal fork of apache/pulsar to run the builds in your "personal 
> >>> CI". There's more details in the previous emails in this thread.
> >>> 
> >>> -Lari
> >>> 
> >>> [1] - build queue: 
> >>> https://github.com/apache/pulsar/actions?query=is%3Aqueued
> >>> 
> >>> On 2022/08/30 12:39:19 Lari Hotari wrote:
>  Pulsar CI continues to be congested, and the build queue is long.
>  
>  I would strongly advice everyone to use "personal CI" to mitigate the 
>  issue of the long delay of CI feedback. You can simply open a PR to your 
>  own personal fork of apache/pulsar to run the builds in your "personal 
>  CI". There's more details in the previous email in this thread.
>  
>  Some updates:
>  
>  There has been a discussion with Gavin McDonald from ASF infra on 
>  the-asf slack about getting usage reports from GitHub to support the 
>  investigation. Slack thread is the same one mentioned in the previous 
>  email, https://the-asf.slack.com/archives/CBX4TSBQ8/p1661512133913279 . 
>  Gavin already requested the usage report in GitHub UI, but it produced 
>  invalid results.
>  
>  I made a change to mitigate a source of additional GitHub Actions 
>  overhead. 
>  In the past, each cherry-picked commit to a maintenance branch of Pulsar 
>  has triggered a lot of workflow runs. 
>  
>  The solution for cancelling duplicate builds automatically is to add 
>  this definition to the workflow definition:
>  concurrency:
>   group: ${{ github.workflow }}-${{ github.ref }}
>   cancel-in-progress: true
>  
>  I added this to all maintenance branch GitHub Actions workflows:
>  
>  branch-2.10 change:
>  https://github.com/apache/pulsar/commit/5d2c9851f4f4d70bfe74b1e683a41c5a040a6ca7
>  branch-2.9 change:
>  https://github.com/apache/pulsar/commit/3ea124924fecf636cc105de75c62b3a99050847b
>  branch-2.8 change:
>  https://github.com/apache/pulsar/commit/48187bb5d95e581f8322a019b61d986e18a31e54
>  branch-2.7:
>  https://github.com/apache/pulsar/commit/744b62c99344724eacdbe97c881311869d67f630
>  
>  branch-2.11 already contains the necessary config for cancelling 
>  duplicate builds.
>  
>  The benefit of the above change is that when multiple commits are 
>  cherry-picked to a branch at once, only the build of the last commit 
>  will get run eventually. The builds for the intermediate commits will 
>  get cancelled. Obviously there's a tradeoff here that we don't get the 
>  information if one of the earlier commits breaks the build. It's the 
>  cost that we need to pay. Nevertheless our build is so flaky that it's 
>  hard to determine whether a failed build result is only caused by bad 
>  flaky test or whether it's an actual failure. Because of this we don't 
>  lose anything by cancelling builds. It's more important to save build 
>  resources. In the maintenance branches for 2.10 and older, the average 
>  total build time consumed is around 20 hours which is a lot.
>  
>  At this time, the overhead of maintenance branch builds doesn't seem to 
>  be the source of the problems. There must be some other issue which is 
>  possibly related to exceeding a usage quota. Hopefully we get the CI 

Re: [DISCUSS] Improvements on the release process

[Yu]

Hi Yunze,

Thanks for updating the workflow!

~~

Hi all,

For the release process, we've updated the doc-related workflow [1] since
we changed the doc maintenance strategy [2].

TL;DR
Breaking change:
For release managers: from 2.8.x, you do not need to generate
an independent doc set for each release.

~~

[1] Workflow changes:

- For doc contributors:
https://docs.google.com/document/d/1-1uJyd1k9_h56xiiVRVOnrLcCnTmg9n7SrHhNVNEEi4/edit#bookmark=id.q5m2r5pimdi6

- For release managers:
https://github.com/apache/pulsar/pull/17130/files#diff-f3115b8be648c3dc440594799619e7ce4408a34efab13b9d57a902030b62562c

[2] https://github.com/apache/pulsar/issues/16637

~~

Feel free to comment, thank you!

Yu

On Tue, Sep 6, 2022 at 10:57 AM Yunze Xu 
wrote:

> Hi all,
>
> I'm working on 2.8.4 release recently. When I followed the release
> process, I found many steps are outdated so that I turned to the
> previous release managers for help frequently. Since the release
> process is now in the codebase [1], I opened a PR for some
> improvements on it. [2]
>
> PTAL especially if you have been a release manager before.
>
> [1] https://lists.apache.org/thread/mv1to079cznkxdldrpoq5518l2ozl5kr
> [2] https://github.com/apache/pulsar/pull/17470
>
> Thanks,
> Yunze
>
>
>
>
>

Re: [DISCUSS] Call to improve Pulsar contributor's experience

[Yu]

Thank you Lari!

Except for updating .md docs, we need to update various API docs [1]. These
docs are generated from code automatically (annotations in code files).

For these special doc PRs, can we set them to run only build (compile)
tests and skip other code tests?

~~

[1]

Admin API docs:
- pulsar-admin: update
https://github.com/apache/pulsar/tree/master/pulsar-client-tools/src/main/java/org/apache/pulsar/admin/cli
- REST API: update
https://github.com/apache/pulsar/tree/master/pulsar-broker/src/main/java/org/apache/pulsar
- Java admin API: update
https://github.com/apache/pulsar/tree/master/pulsar-client-admin-api/src/main/java/org/apache/pulsar/client/admin


Client API docs:
- Java: update
https://github.com/apache/pulsar/tree/master/pulsar-client-api/src/main/java/org/apache/pulsar/client/api
- CPP: update
https://github.com/apache/pulsar/tree/master/pulsar-client-cpp/include/pulsar
- Python: have no idea

~~

Thank you!

Yu


On Fri, Sep 2, 2022 at 1:17 AM Lari Hotari  wrote:

> On 2022/09/01 08:36:11 Yu wrote:
> > # 1
> > For pure doc PRs (only update .md files), do they run the same tests as
> > code PRs?
> > If so, can we set them to run only doc-related tests and skip code tests
> > (since they're easily failed)?
> > In this way, docs can be iterated faster.
>
> The solution is already in place where the CI pipeline for docs is
> expedited.
> Some technical details about the solution: All builds steps in the GitHub
> Actions workflow build jobs are skipped for PRs that include changes only
> to docs. The reason why the workflows and build jobs aren't completely
> skipped is that we use the "required checks" feature and it is necessary to
> run all required checks also for PRs with only doc changes.
>
> >
> > 
> >
> > # 2
> > Does it make sense to add instructions for tests to the Pulsar
> Contribution
> > Guide?
> >
> > For example,
> >
> > * For users:
> > - How to resolve test issues (common test failure reasons and solutions)
> > - Who can ask for help if users are blocked and can not resolve problems
> > themselves
> > - How to report test bugs
> >
> > * For developers:
> > - How do tests work? (mechanism, Apache rules, etc)
> > - How can I add/update tests? (quotas [1], limitations, notes, etc)
>
> Good suggestions.
>
> In general, I hope we find better ways to listen to the voice of our
> contributors. What is their contribution experience? How did they feel
> about it?
>
> Perhaps we could decide to conduct surveys? GitHub discussions has support
> for polls [1] so that is one option as a technical solution for asking for
> feedback in a way where there would be a low barrier to respond.
>
> -Lari
>
> [1] https://github.blog/changelog/2022-04-12-discussions-polls/
>

Re: [DISCUSS] Call to improve Pulsar contributor's experience

[Yu]

Hi Lari,

Thanks for raising this up! May I know your thoughts on these questions?



# 1
For pure doc PRs (only update .md files), do they run the same tests as
code PRs?
If so, can we set them to run only doc-related tests and skip code tests
(since they're easily failed)?
In this way, docs can be iterated faster.



# 2
Does it make sense to add instructions for tests to the Pulsar Contribution
Guide?

For example,

* For users:
- How to resolve test issues (common test failure reasons and solutions)
- Who can ask for help if users are blocked and can not resolve problems
themselves
- How to report test bugs

* For developers:
- How do tests work? (mechanism, Apache rules, etc)
- How can I add/update tests? (quotas [1], limitations, notes, etc)



[1] https://github.com/apache/pulsar/issues/16439#issuecomment-1182832309



Thank you!

On Thu, Sep 1, 2022 at 4:11 PM Lari Hotari  wrote:

> Hi,
>
> I think that we would need to improve the experience for contributors.
> It's currently a big challenge to get a PR to the state where tests pass,
> mainly because of the large amount of flaky tests and frequent congestions
> in Pulsar CI. We don't tell this to the contributors in the PR template [1]
> or the contributors guide [2] and finding this out without anyone
> explaining could be a frustrating experience.
>
> Let's improve our contributor experience. "The hard part isn't solving the
> problems, it's identifying the right problems to solve." [3]
>
> Would someone like to share their Pulsar contribution experience and what
> you think that needs improvement? What was painful?
>
> -Lari
>
> [1]
> https://raw.githubusercontent.com/apache/pulsar/master/.github/PULL_REQUEST_TEMPLATE.md
> [2] https://pulsar.apache.org/contributing/
> [3] https://www.youtube.com/watch?v=qqaOpSJKdWc ,
> https://leanpub.com/ideaflow . Janelle Arty Starr: "Idea Flow: How to
> Measure the PAIN in Software Development"
>

Re: [Discussion] PIP 198 - How to define [type] and [scope]?

[Yu]

Thank you tison!

We don't explicitly set the rules for issue titles and force ppl to follow.

Just suggest you can follow the same rule to write issue titles if you
ensure the involved [type] and [scope] like this example [1].
Otherwise, you can write as usual.

[1] https://github.com/apache/pulsar/issues/14928

Yu

On Thu, Aug 25, 2022 at 1:16 PM tison  wrote:

> Anyway, it's a separate topic to discuss. If you want to discuss issue
> types and whether to label components, please start another thread.
>
> Best,
> tison.
>
>
> tison  于2022年8月25日周四 13:12写道：
>
> > From current issue templates, we already sort issues into bug reports,
> > improvements, doc changes, flaky tests, and PIPs. They're types. [type]
> and
> > [component] described here are applied to commit messages, not for
> issues.
> >
> > For components, we may encourage contributors to try their best to sort
> > out related components, but it's generally hard to do. I report a bug,
> how
> > can I know which components are related? It is required I have to dig it
> > out?
> >
> > Best,
> > tison.
> >
> >
> > tison  于2022年8月25日周四 13:08写道：
> >
> >> > Agree with applying the same rules ( [type] [scope] summary) for
> >> writing issue titles.
> >>
> >> It cannot be guarded by check so I think it only increases contributors'
> >> overhead.
> >>
> >> Instead, we can try to find out some integration if we can use the
> GitHub
> >> issue forms dropdown widget to allow contributors to tag the issue.
> >>
> >> I don't know whether it's possible, but it's better than setting up
> title
> >> rules. I can foresee that it's seldomly followed.
> >>
> >> Best,
> >> tison.
> >>
> >>
> >> Liu Yu  于2022年8月25日周四 12:59写道：
> >>
> >>> Thanks Max!
> >>>
> >>> Agree with applying the same rules ( [type] [scope] summary) for
> writing
> >>> issue titles.
> >>>
> >>> On 2022/08/25 02:48:51 Max Xu wrote:
> >>> > LGTM.
> >>> >
> >>> > And I think we should also update our issue templates.
> >>> >
> >>> > Best,
> >>> > Max Xu
> >>> >
> >>> >
> >>> > On Tue, Aug 23, 2022 at 6:04 PM Yu  wrote:
> >>> >
> >>> > > Hi team,
> >>> > >
> >>> > > Many thanks for your feedback! We've adjusted the convention based
> >>> on your
> >>> > > suggestions!
> >>> > >
> >>> > > Below is a brief summary of what we have reached a consensus on:
> >>> > >
> >>> > > 
> >>> > >
> >>> > > 1. Convention
> >>> > >
> >>> > > Continue to follow our existing convention (it's customized on
> >>> Agular) [1]
> >>> > >
> >>> > > 
> >>> > >
> >>> > > 2. Definition
> >>> > >
> >>> > > [type] must be one of the following:
> >>> > > - feat (abbr for "feature")
> >>> > > - improve
> >>> > > - fix
> >>> > > - cleanup
> >>> > > - refactor
> >>> > > - revert
> >>> > >
> >>> > > [scope] must be one of the following:
> >>> > > - admin
> >>> > > - broker
> >>> > > - cli (changes to CLI tools)
> >>> > > - io
> >>> > > - fn (abbr for "function")
> >>> > > - meta (abbr for "metadata")
> >>> > > - monitor
> >>> > > - proxy
> >>> > > - schema
> >>> > > - sec (abbr for "security")
> >>> > > - sql
> >>> > > - storage
> >>> > > - offload (changes to tiered storage)
> >>> > > - txn
> >>> > > - java
> >>> > > - cpp
> >>> > > - py
> >>> > > - ws (changes to WebSocket)
> >>> > > - test (changes to code tests)
> >>> > > - ci (changes to CI workflow)
> >>> > > - build (changes to dependencies, docker, build or release script)
> >>> > > - misc
> >>> > > - doc
> >>> > > - blog
> >>> > > - site
> >>> > &g

[VOTE RESULT] PIP 198: Standardize PR Naming Convention using GitHub Actions

[Yu]

Hi team,

As discussed previously [1], we'll start implementing PIP 198: Standardize
PR Naming Convention using GitHub Actions [1] based on the results voted by
the community.

Below is a brief summary of the vote results.



1. Convention

Continue to follow our existing convention (it's customized on Agular) [3]



2. Definition

[type] must be one of the following:
- feat (abbr for "feature")
- improve
- fix
- cleanup
- refactor
- revert

[scope] must be one of the following:
- admin
- broker
- cli (changes to CLI tools)
- io
- fn (abbr for "function")
- meta (abbr for "metadata")
- monitor
- proxy
- schema
- sec (abbr for "security")
- sql
- storage
- offload (changes to tiered storage)
- txn
- java
- cpp
- py
- ws (changes to WebSocket)
- test (changes to code tests)
- ci (changes to CI workflow)
- build (changes to dependencies, docker, build or release script)
- misc
- doc
- blog
- site

For full details, see [Guide] Pulsar Pull Request Naming Convention [4]



[1] https://lists.apache.org/thread/11hpppllkh68zodromd7pzn173gb9hgl
[2]
https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1
[3] https://lists.apache.org/thread/90rcjf1dv0fbkb5hm31kmgr65fj0nfnn
[4]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno



Yu, mangoGoForward, Max

Re: [Discussion] PIP 198 - How to define [type] and [scope]?

[Liu Yu]

Thanks Max! 

Agree with applying the same rules ( [type] [scope] summary) for writing issue 
titles.

On 2022/08/25 02:48:51 Max Xu wrote:
> LGTM.
> 
> And I think we should also update our issue templates.
> 
> Best,
> Max Xu
> 
> 
> On Tue, Aug 23, 2022 at 6:04 PM Yu  wrote:
> 
> > Hi team,
> >
> > Many thanks for your feedback! We've adjusted the convention based on your
> > suggestions!
> >
> > Below is a brief summary of what we have reached a consensus on:
> >
> > 
> >
> > 1. Convention
> >
> > Continue to follow our existing convention (it's customized on Agular) [1]
> >
> > 
> >
> > 2. Definition
> >
> > [type] must be one of the following:
> > - feat (abbr for "feature")
> > - improve
> > - fix
> > - cleanup
> > - refactor
> > - revert
> >
> > [scope] must be one of the following:
> > - admin
> > - broker
> > - cli (changes to CLI tools)
> > - io
> > - fn (abbr for "function")
> > - meta (abbr for "metadata")
> > - monitor
> > - proxy
> > - schema
> > - sec (abbr for "security")
> > - sql
> > - storage
> > - offload (changes to tiered storage)
> > - txn
> > - java
> > - cpp
> > - py
> > - ws (changes to WebSocket)
> > - test (changes to code tests)
> > - ci (changes to CI workflow)
> > - build (changes to dependencies, docker, build or release script)
> > - misc
> > - doc
> > - blog
> > - site
> >
> > For full details, see [Guide] Pulsar Pull Request Naming Convention [2]
> >
> > 
> >
> > If you have any concerns, feel free to comment before 13:00 August 25 (UTC
> > +8).
> >
> > We'll start implementing it if there is no objection after that time.
> >
> > Thank you!
> >
> > 
> >
> > [1] https://lists.apache.org/thread/90rcjf1dv0fbkb5hm31kmgr65fj0nfnn
> > [2]
> >
> > https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
> >
> > Yu and mangoGoForward
> >
> > On Tue, Aug 23, 2022 at 5:59 PM Yu  wrote:
> >
> > > Hi Jiuming, Yunze, tison,
> > > Thanks for your vote!
> > >
> > > 
> > >
> > > Hi tison,
> > >
> > > > "packaging logics"
> > > > For example, build the docker image, build & publish shell scripts.
> > >
> > > If you refer to these changes, they belong to [build] scope.
> > >
> > > Yu and Zixuan
> > >
> > > On Tue, Aug 23, 2022 at 1:25 PM tison  wrote:
> > >
> > >> Hi Yu,
> > >>
> > >> Reply inline:
> > >>
> > >> > Besides, the existing scope, [tool], refers to Pulsar CLI tools [1].
> > >> > We're considering to rename it to [cli] since:
> > >>
> > >> Make sense.
> > >>
> > >> > "deployment logic" If so, can we ignore this?
> > >>
> > >> I saw you already remove [deploy] scope. No comment here. It should be
> > >> fine.
> > >>
> > >> > "packaging logics"
> > >>
> > >> For example, build the docker image, build & publish shell scripts.
> > >>
> > >> >  How about defining [build] refer to the following?
> > >>
> > >> Make sense.
> > >>
> > >> > Two quick questions need your vote!
> > >>
> > >> To save letters, B & A.
> > >>
> > >> Best,
> > >> tison.
> > >>
> > >
> >
> 

Re: [Discussion] PIP 78: Replace brodocs with docsify?

[Yu]

Hi Dave, thanks for your great reminder! We'll add those rules.

Yu, signormercurio, urfreespace

On Tue, Aug 23, 2022 at 10:33 PM Dave Fisher  wrote:

> If page urls change then we should also add http redirect rules to help
> users who bookmarked these docs.
>
> Sent from my iPhone
>
> > On Aug 23, 2022, at 5:53 AM, Yu  wrote:
> >
> > Hi team,
> >
> > Now is 3 working days after the initial discussion
> >
> > We'll start replacing brodocs with docsify for docs since there is no
> > objection or technical suggestions.
> >
> > Yu, signormercurio, urfreespace
> >
> >> On Fri, Aug 19, 2022 at 5:09 PM Yu  wrote:
> >>
> >> Thanks Dave!
> >>
> >>> How is this search organized on the server and how would this integrate
> >> with algolia?
> >>
> >> Search is performed at the front end, and it does not need to integrate
> >> with Algolia.
> >>
> >>> Google Analytics will be disallowed on ASF project sites very soon due
> >> to Privacy concerns with tracking data. I’ve warned about this several
> >> times. Please eliminate GA. If we need to track then we have options.
> >>
> >> Listing GA here just shows docsify's capabilities.
> >> As we discussed before [1], GA will no longer process new data in
> standard
> >> properties beginning July 1, 2023.
> >> Matteo is being considered to replace it.
> >>
> >> [1] https://github.com/apache/pulsar/issues/15664
> >>
> >> Yu and signormercurio
> >>
> >>
> >>
> >>
> >>
> >>
> >>> On Thu, Aug 18, 2022 at 9:46 PM Dave Fisher 
> wrote:
> >>>
> >>>
> >>>
> >>> Sent from my iPhone
> >>>
> >>>> On Aug 18, 2022, at 4:55 AM, Yu  wrote:
> >>>>
> >>>> Hi team,
> >>>>
> >>>> To reduce manual work, we’re constantly implementing PIP 78: Generate
> >>> Docs
> >>>> from Code Automatically [1].
> >>>>
> >>>> Docs here refer to the following：
> >>>> - Connector configurations [2]
> >>>> - Client configurations [3]
> >>>> - Pulsar CLI tools [4]
> >>>> - Pulsar configurations [5]
> >>>> - pulsar-admin [6]
> >>>>
> >>>> # Question
> >>>>
> >>>> Currently, some of the docs above [7] are generated using brodocs [8].
> >>>> We’re wondering if it makes sense to replace brodocs with docsify?
> >>>>
> >>>> # docsify benefits
> >>>>
> >>>> ## For users
> >>>> - Enjoy new features (eg. search, copy to clipboard, language
> >>> highlighting,
> >>>> tabs, Disqus, etc.)
> >>>
> >>> How is this search organized on the server and how would this integrate
> >>> with algolia?
> >>>
> >>>> - More clear and organized layout
> >>>>
> >>>> ## For doc maintainers
> >>>> - Simple and lightweight
> >>>> - No statically built HTML files. Instead, it smartly loads and parses
> >>> .md
> >>>> files and displays them as a website.
> >>>> - Allow feature customization
> >>>> - Able to work with Google Analytics to track data
> >>>
> >>> Google Analytics will be disallowed on ASF project sites very soon due
> to
> >>> Privacy concerns with tracking data. I’ve warned about this several
> times.
> >>> Please eliminate GA. If we need to track then we have options.
> >>>
> >>> Also we never discuss GA anywhere within the PMC or developer
> community.
> >>> What value does it have?
> >>>
> >>> Dave
> >>>
> >>>>
> >>>> # Demo
> >>>>
> >>>> We’ve created a demo here [9].
> >>>> This demo is only for demonstration purposes, so we just add a few
> >>>> improvements. It can be iterated later.
> >>>>
> >>>> 
> >>>>
> >>>> If docsify is better, we’ll use it for all the docs above to provide a
> >>>> consistent content experience.
> >>>>
> >>>> Feel free to check and comment, thank you!
> >>>>
> >>>> [1] https://lists.apache.org/thread/638q6kmq81z2qjmyhgkqzp00sllh4x0w
> >>>> [2] https://pulsar.apache.org/docs/next/io-connectors (Configurations
> >>> for
> >>>> each connector)
> >>>> [3] https://pulsar.apache.org/docs/next/client-libraries-java
> >>>> (Configuration for each client. Here takes Java client as an example,
> it
> >>>> refers to configurations of client, producer, consumer, and reader)
> >>>> [4] https://pulsar.apache.org/docs/next/reference-cli-tools
> >>>> [5] https://pulsar.apache.org/docs/next/reference-configuration
> >>>> [6] https://pulsar.apache.org/tools/pulsar-admin/
> >>>> [7] https://pulsar.apache.org/tools/
> >>>> [8] https://github.com/Birdrock/brodocs
> >>>> [9] https://pulsar.apache.org/tools/pulsar-config/2.11.0-SNAPSHOT/#/
> >>>>
> >>>> Yu, signormercurio, urfreespace
> >>>
> >>>
>
>

Re: [DISCUSS] Move PIPs to the codebase?

[Yu]

Hi Penghui, Thanks for raising this up!

> we should have a discussion first on the mailing list, just get feedback
on the
> motivation. If there are no objections,
> the proposal owner can add a line to the file with the PIP number through
> a PR, like PIP-123: xxx (Under Discussion).
> So that we can prevent the duplicated PIP number

This is a good idea to ensure no NO. is re-used or jumped over.

As you explained, we can act like this:

1. Send the PIP idea to the community without using a NO.

2. After the idea is approved, add "PIP 123 (under discussion)" to the "PIP
metadata" file.

3. ...

Yu


On Wed, Aug 24, 2022 at 10:01 AM PengHui Li  wrote:

> Hi Rajan,
>
> > I didn't understand this part. You want one to create a PR before
> submitting a proposal? That's clearly not a good idea because if the PIP
> approach will change then the entire development effort will be wasted and
> that's the whole purpose of PIP. I guess creating PIP into an issue and
> discussing the issue is definitely working and it's an easier way to
> discuss quickly rather than discussing over email threads.
>
> Sorry, I mean create a PR to add the proposal, not the implementation.
> Before adding the proposal, we should discuss the motivation on the mailing
> list first.
>
> > Let's not change this practice without good discussion and agreement from
> the community.
>
> I don't think this essentially changes this part, it just provides a way
> for reviewers to
> review the details of the proposal more efficiently. For a quick
> discussion, this will not change
> it. Let me try to clarify the procedure after we applied this idea
>
>
>1. Send the email first to discuss the motivation of your proposal
>2. Discuss the motivation under the mailing list and request a PIP
>number if there are no objections
>3. Create a PR to add the detailed proposal
>4. *Send out the VOTE email with the PR link*
>5. *Review the proposal(The PR) on Github and vote under the mailing
>list.*
>6. Merge the PR of the proposal after the proposal get 3 (+1) bindings
>
> The only difference is step 4 and step 5. Currently, we share the issue
> link to ask for a review.
>
> Thanks,
> Penghui
>
> On Wed, Aug 24, 2022 at 1:22 AM Rajan Dhabalia 
> wrote:
>
> > Hi,
> >
> > >>> I think we can move all the PIPs to the codebase and the new proposal
> > and proposal without any reviews should happen with a PR first. So that
> we
> > can review and comment easily.
> >
> > I didn't understand this part. You want one to create a PR before
> > submitting a proposal? That's clearly not a good idea because if the PIP
> > approach will change then the entire development effort will be wasted
> and
> > that's the whole purpose of PIP. I guess creating PIP into an issue and
> > discussing the issue is definitely working and it's an easier way to
> > discuss quickly rather than discussing over email threads.
> >
> > Let's not change this practice without good discussion and agreement from
> > the community.
> >
> > Thanks,
> > Rajan
> >
> > On Thu, Aug 18, 2022 at 8:27 AM PengHui Li  wrote:
> >
> > > Hi all,
> > >
> > > Currently, the new proposal will be added to the issue list and then
> > shared
> > > link in the email
> > > to request the proposal review. It's really hard to review a long
> > proposal
> > > if you want to comment
> > > in detail.
> > >
> > > Here is an example:
> > > https://github.com/apache/pulsar/issues/16763#issuecomment-1219606491
> > > This seems very unintuitive.
> > >
> > > I think we can move all the PIPs to the codebase and the new proposal
> and
> > > proposal without
> > > any reviews should happen with a PR first. So that we can review and
> > > comment easily.
> > > Certainly, all the votes should happen on the mailing list. And we can
> > also
> > > discuss the
> > > proposal on the mailing list.
> > >
> > > Following this way, we don't need to sync the PIPs from the issue to
> the
> > > wiki page.
> > > We can just add a link that points to the PIPs dir to the contribution
> > > guide or README.
> > >
> > > We have another pain point about the duplicated PIP number. We can
> > maintain
> > > a file, a list of
> > > all the proposal contains the approved, in-review, drafting. Before
> > > creating a proposal, we should
> > > have a discussion first on the mailing list, just get feedback on the
> > > motivation. If there are no objections,
> > > the proposal owner can add a line to the file with the PIP number
> > through a
> > > PR, like PIP-123: xxx (Under Discussion).
> > > So that we can prevent the duplicated PIP number(which will conflict if
> > > someone merged first).
> > > After the PR is merged, we can send out a new PR to add the proposal.
> > >
> > > Thanks,
> > > Penghui
> > >
> >
>

Re: [Discussion] PIP 78: Replace brodocs with docsify?

[Yu]

Hi team,

Now is 3 working days after the initial discussion

We'll start replacing brodocs with docsify for docs since there is no
objection or technical suggestions.

Yu, signormercurio, urfreespace

On Fri, Aug 19, 2022 at 5:09 PM Yu  wrote:

> Thanks Dave!
>
> > How is this search organized on the server and how would this integrate
> with algolia?
>
> Search is performed at the front end, and it does not need to integrate
> with Algolia.
>
> > Google Analytics will be disallowed on ASF project sites very soon due
> to Privacy concerns with tracking data. I’ve warned about this several
> times. Please eliminate GA. If we need to track then we have options.
>
> Listing GA here just shows docsify's capabilities.
> As we discussed before [1], GA will no longer process new data in standard
> properties beginning July 1, 2023.
> Matteo is being considered to replace it.
>
> [1] https://github.com/apache/pulsar/issues/15664
>
> Yu and signormercurio
>
>
>
>
>
>
> On Thu, Aug 18, 2022 at 9:46 PM Dave Fisher  wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> > On Aug 18, 2022, at 4:55 AM, Yu  wrote:
>> >
>> > Hi team,
>> >
>> > To reduce manual work, we’re constantly implementing PIP 78: Generate
>> Docs
>> > from Code Automatically [1].
>> >
>> > Docs here refer to the following：
>> > - Connector configurations [2]
>> > - Client configurations [3]
>> > - Pulsar CLI tools [4]
>> > - Pulsar configurations [5]
>> > - pulsar-admin [6]
>> >
>> > # Question
>> >
>> > Currently, some of the docs above [7] are generated using brodocs [8].
>> > We’re wondering if it makes sense to replace brodocs with docsify?
>> >
>> > # docsify benefits
>> >
>> > ## For users
>> > - Enjoy new features (eg. search, copy to clipboard, language
>> highlighting,
>> > tabs, Disqus, etc.)
>>
>> How is this search organized on the server and how would this integrate
>> with algolia?
>>
>> > - More clear and organized layout
>> >
>> > ## For doc maintainers
>> > - Simple and lightweight
>> > - No statically built HTML files. Instead, it smartly loads and parses
>> .md
>> > files and displays them as a website.
>> > - Allow feature customization
>> > - Able to work with Google Analytics to track data
>>
>> Google Analytics will be disallowed on ASF project sites very soon due to
>> Privacy concerns with tracking data. I’ve warned about this several times.
>> Please eliminate GA. If we need to track then we have options.
>>
>> Also we never discuss GA anywhere within the PMC or developer community.
>> What value does it have?
>>
>> Dave
>>
>> >
>> > # Demo
>> >
>> > We’ve created a demo here [9].
>> > This demo is only for demonstration purposes, so we just add a few
>> > improvements. It can be iterated later.
>> >
>> > 
>> >
>> > If docsify is better, we’ll use it for all the docs above to provide a
>> > consistent content experience.
>> >
>> > Feel free to check and comment, thank you!
>> >
>> > [1] https://lists.apache.org/thread/638q6kmq81z2qjmyhgkqzp00sllh4x0w
>> > [2] https://pulsar.apache.org/docs/next/io-connectors (Configurations
>> for
>> > each connector)
>> > [3] https://pulsar.apache.org/docs/next/client-libraries-java
>> > (Configuration for each client. Here takes Java client as an example, it
>> > refers to configurations of client, producer, consumer, and reader)
>> > [4] https://pulsar.apache.org/docs/next/reference-cli-tools
>> > [5] https://pulsar.apache.org/docs/next/reference-configuration
>> > [6] https://pulsar.apache.org/tools/pulsar-admin/
>> > [7] https://pulsar.apache.org/tools/
>> > [8] https://github.com/Birdrock/brodocs
>> > [9] https://pulsar.apache.org/tools/pulsar-config/2.11.0-SNAPSHOT/#/
>> >
>> > Yu, signormercurio, urfreespace
>>
>>

Re: [Discussion] PIP 198 - How to define [type] and [scope]?

[Yu]

Hi team,

Many thanks for your feedback! We've adjusted the convention based on your
suggestions!

Below is a brief summary of what we have reached a consensus on:



1. Convention

Continue to follow our existing convention (it's customized on Agular) [1]



2. Definition

[type] must be one of the following:
- feat (abbr for "feature")
- improve
- fix
- cleanup
- refactor
- revert

[scope] must be one of the following:
- admin
- broker
- cli (changes to CLI tools)
- io
- fn (abbr for "function")
- meta (abbr for "metadata")
- monitor
- proxy
- schema
- sec (abbr for "security")
- sql
- storage
- offload (changes to tiered storage)
- txn
- java
- cpp
- py
- ws (changes to WebSocket)
- test (changes to code tests)
- ci (changes to CI workflow)
- build (changes to dependencies, docker, build or release script)
- misc
- doc
- blog
- site

For full details, see [Guide] Pulsar Pull Request Naming Convention [2]



If you have any concerns, feel free to comment before 13:00 August 25 (UTC
+8).

We'll start implementing it if there is no objection after that time.

Thank you!



[1] https://lists.apache.org/thread/90rcjf1dv0fbkb5hm31kmgr65fj0nfnn
[2]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno

Yu and mangoGoForward

On Tue, Aug 23, 2022 at 5:59 PM Yu  wrote:

> Hi Jiuming, Yunze, tison,
> Thanks for your vote!
>
> 
>
> Hi tison,
>
> > "packaging logics"
> > For example, build the docker image, build & publish shell scripts.
>
> If you refer to these changes, they belong to [build] scope.
>
> Yu and Zixuan
>
> On Tue, Aug 23, 2022 at 1:25 PM tison  wrote:
>
>> Hi Yu,
>>
>> Reply inline:
>>
>> > Besides, the existing scope, [tool], refers to Pulsar CLI tools [1].
>> > We're considering to rename it to [cli] since:
>>
>> Make sense.
>>
>> > "deployment logic" If so, can we ignore this?
>>
>> I saw you already remove [deploy] scope. No comment here. It should be
>> fine.
>>
>> > "packaging logics"
>>
>> For example, build the docker image, build & publish shell scripts.
>>
>> >  How about defining [build] refer to the following?
>>
>> Make sense.
>>
>> > Two quick questions need your vote!
>>
>> To save letters, B & A.
>>
>> Best,
>> tison.
>>
>

Re: [Discussion] PIP 198 - How to define [type] and [scope]?

[Yu]

Hi Jiuming, Yunze, tison,
Thanks for your vote!



Hi tison,

> "packaging logics"
> For example, build the docker image, build & publish shell scripts.

If you refer to these changes, they belong to [build] scope.

Yu and Zixuan

On Tue, Aug 23, 2022 at 1:25 PM tison  wrote:

> Hi Yu,
>
> Reply inline:
>
> > Besides, the existing scope, [tool], refers to Pulsar CLI tools [1].
> > We're considering to rename it to [cli] since:
>
> Make sense.
>
> > "deployment logic" If so, can we ignore this?
>
> I saw you already remove [deploy] scope. No comment here. It should be
> fine.
>
> > "packaging logics"
>
> For example, build the docker image, build & publish shell scripts.
>
> >  How about defining [build] refer to the following?
>
> Make sense.
>
> > Two quick questions need your vote!
>
> To save letters, B & A.
>
> Best,
> tison.
>

Re: [Discussion] PIP 198 - How to define [type] and [scope]?

[Yu]

Hi developers,

Two quick questions need your vote!

Which do you prefer?



# 1. Use "branch" or "BP"?

Choice A: [fix][broker][branch-2.9] xxx
Choice B: [fix][broker][BP-2.9] xxx



# 2. for the [scope], use "misc" or "chore"? [1]

Choice A: misc
Choice B: chore



Thank you all!

[1]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.58q1qxhu7pio

Yu

On Mon, Aug 22, 2022 at 12:44 PM Yu  wrote:

> Hi tison,
>
> Thanks for your suggestions! We have several questions on [build]:
>
> > build - all things related to the build system, including tools,
> deployment logic, maven changes, packaging logics, docker image, build
> scripts.
>
> 
>
> # 1.  "tools"
>
> What do you refer to? Plugins?
>
> Besides, the existing scope, [tool], refers to Pulsar CLI tools [1].
> We're considering to rename it to [cli] since:
> a. "cli" is more clear and short
> b. Save the word "tool" for future use
>
> Does it make sense?
>
> 
>
> # 2. "deployment logic"
>
> Seems that it's an obsolete module and has not been updated for a long
> while.
> If so, can we ignore this?
>
> 
>
> # 3. Does "packaging logics" belong to [admin]? [2]
>
> 
>
> # 4. How about defining [build] refer to the following?
>
> - Dependency (Maven)
>
> In this way, we do not have the scope [dependency] since the changes to
> dependency belong to [build].
>
> - Docker
>
> - Build or release script
>
> 
>
> Thank you for your reply!
>
> [1]
> https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.khz275ok35u5
> [2]
> https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.nnekhkthmwlh
>
> Yu and Zixuan
>
> On Mon, Aug 22, 2022 at 12:40 PM Yu  wrote:
>
>> Thank you tison and Zixuan!
>>
>> Agree on the following aspects:
>>
>> 
>>
>> # 1. Remove 3 [scope]s
>>
>> - Remove [workflow] since it can be replaced with other scopes
>> eg.
>> "[feat][workflow] Add instructions for previewing website changes"
>> can be written as
>> "[feat][doc] Add instructions for previewing website changes"
>>
>> - Remove [depoly] since changes to deployment can be represented by other
>> [scope]s.
>>
>> - Remove [pkg]since it refers to package API [1], which belongs to
>> [admin].
>>
>> 
>>
>> # 2. Update 4 [scope]s
>>
>> - Add [meta], which refers to changes to metadata.
>>
>> - Add [storage], which refers to changes to managed ledger.
>>
>> - Rename [ts] to [offloaded], which refers to changes to tiered storage.
>>
>> - Rename [func] to [fn], which refers to changes to function.
>>
>> 
>>
>> # 3. Remain the same
>>
>> These formats are fine to go:
>>
>> - Submit breaking changes
>> [feat][broker]! Support xx
>>
>> - Submit PIP changes
>> [feat][broker] PIP-198: Support xx
>>
>> 
>>
>> Feel free to comment, thank you!
>>
>> 
>>
>> [1] https://pulsar.apache.org/docs/next/admin-api-packages
>>
>> Yu and Zixuan
>>
>> On Fri, Aug 19, 2022 at 6:21 PM Zixuan Liu  wrote:
>>
>>> +1 for fcn -> fn
>>> +1 for ts -> offloader
>>>
>>> +1 * ci - CI workflow changes or debugging.
>>> +1 * build - all things related to the build system, including tools,
>>> deployment logic, maven changes, packaging logics, docker image,
>>> buildscripts.
>>>
>>> `pkg` should belong to the `admin` scope, so suggest using the `admin`
>>> instead `pkg`.
>>>
>>> `tool` is pulsar-admin, pulsar, pulsar-client, and so on cli, so keep
>>> using
>>> the `tool`.
>>>
>>> deploy should belong to the `build` scope`, so suggest using the `build`
>>> instead `deploy`.
>>>
>>>
>>> tison  于2022年8月19日周五 17:46写道：
>>>
>>> > BTW, how can I sort changes for the metadata store?
>>> >
>>> > Best,
>>> > tison.
>>> >
>&

Re: [Discussion] PIP 198 - How to define [type] and [scope]?

[Yu]

Hi tison,

Thanks for your suggestions! We have several questions on [build]:

> build - all things related to the build system, including tools,
deployment logic, maven changes, packaging logics, docker image, build
scripts.



# 1.  "tools"

What do you refer to? Plugins?

Besides, the existing scope, [tool], refers to Pulsar CLI tools [1].
We're considering to rename it to [cli] since:
a. "cli" is more clear and short
b. Save the word "tool" for future use

Does it make sense?



# 2. "deployment logic"

Seems that it's an obsolete module and has not been updated for a long
while.
If so, can we ignore this?



# 3. Does "packaging logics" belong to [admin]? [2]



# 4. How about defining [build] refer to the following?

- Dependency (Maven)

In this way, we do not have the scope [dependency] since the changes to
dependency belong to [build].

- Docker

- Build or release script



Thank you for your reply!

[1]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.khz275ok35u5
[2]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.nnekhkthmwlh

Yu and Zixuan

On Mon, Aug 22, 2022 at 12:40 PM Yu  wrote:

> Thank you tison and Zixuan!
>
> Agree on the following aspects:
>
> 
>
> # 1. Remove 3 [scope]s
>
> - Remove [workflow] since it can be replaced with other scopes
> eg.
> "[feat][workflow] Add instructions for previewing website changes"
> can be written as
> "[feat][doc] Add instructions for previewing website changes"
>
> - Remove [depoly] since changes to deployment can be represented by other
> [scope]s.
>
> - Remove [pkg]since it refers to package API [1], which belongs to [admin].
>
> 
>
> # 2. Update 4 [scope]s
>
> - Add [meta], which refers to changes to metadata.
>
> - Add [storage], which refers to changes to managed ledger.
>
> - Rename [ts] to [offloaded], which refers to changes to tiered storage.
>
> - Rename [func] to [fn], which refers to changes to function.
>
> 
>
> # 3. Remain the same
>
> These formats are fine to go:
>
> - Submit breaking changes
> [feat][broker]! Support xx
>
> - Submit PIP changes
> [feat][broker] PIP-198: Support xx
>
> 
>
> Feel free to comment, thank you!
>
> 
>
> [1] https://pulsar.apache.org/docs/next/admin-api-packages
>
> Yu and Zixuan
>
> On Fri, Aug 19, 2022 at 6:21 PM Zixuan Liu  wrote:
>
>> +1 for fcn -> fn
>> +1 for ts -> offloader
>>
>> +1 * ci - CI workflow changes or debugging.
>> +1 * build - all things related to the build system, including tools,
>> deployment logic, maven changes, packaging logics, docker image,
>> buildscripts.
>>
>> `pkg` should belong to the `admin` scope, so suggest using the `admin`
>> instead `pkg`.
>>
>> `tool` is pulsar-admin, pulsar, pulsar-client, and so on cli, so keep
>> using
>> the `tool`.
>>
>> deploy should belong to the `build` scope`, so suggest using the `build`
>> instead `deploy`.
>>
>>
>> tison  于2022年8月19日周五 17:46写道：
>>
>> > BTW, how can I sort changes for the metadata store?
>> >
>> > Best,
>> > tison.
>> >
>> >
>> > tison  于2022年8月19日周五 17:44写道：
>> >
>> > > To proposal a workable solution, I suggest:
>> > >
>> > > replace
>> > >
>> > > * pkg
>> > > * tool
>> > > * deploy
>> > > * ci
>> > > * workflow
>> > > * build
>> > >
>> > > with
>> > >
>> > > * ci - CI workflow changes or debugging.
>> > > * build - all things related to the build system, including tools,
>> > > deployment logic, maven changes, packaging logics, docker image, build
>> > > scripts.
>> > >
>> > > Best,
>> > > tison.
>> > >
>> > >
>> > > tison  于2022年8月19日周五 17:41写道：
>> > >
>> > >> > I intended to mean changes to "process / standard / guide" [2]
>> rather
>> > >> than "CI workflow", but it still causes confusion.
>> > >>
>> > >> How can a PR be relevant to these things? I think the result should
>> be
&

Re: [Discussion] PIP 198 - How to define [type] and [scope]?

[Yu]

Thank you tison and Zixuan!

Agree on the following aspects:



# 1. Remove 3 [scope]s

- Remove [workflow] since it can be replaced with other scopes
eg.
"[feat][workflow] Add instructions for previewing website changes"
can be written as
"[feat][doc] Add instructions for previewing website changes"

- Remove [depoly] since changes to deployment can be represented by other
[scope]s.

- Remove [pkg]since it refers to package API [1], which belongs to [admin].



# 2. Update 4 [scope]s

- Add [meta], which refers to changes to metadata.

- Add [storage], which refers to changes to managed ledger.

- Rename [ts] to [offloaded], which refers to changes to tiered storage.

- Rename [func] to [fn], which refers to changes to function.



# 3. Remain the same

These formats are fine to go:

- Submit breaking changes
[feat][broker]! Support xx

- Submit PIP changes
[feat][broker] PIP-198: Support xx



Feel free to comment, thank you!



[1] https://pulsar.apache.org/docs/next/admin-api-packages

Yu and Zixuan

On Fri, Aug 19, 2022 at 6:21 PM Zixuan Liu  wrote:

> +1 for fcn -> fn
> +1 for ts -> offloader
>
> +1 * ci - CI workflow changes or debugging.
> +1 * build - all things related to the build system, including tools,
> deployment logic, maven changes, packaging logics, docker image,
> buildscripts.
>
> `pkg` should belong to the `admin` scope, so suggest using the `admin`
> instead `pkg`.
>
> `tool` is pulsar-admin, pulsar, pulsar-client, and so on cli, so keep using
> the `tool`.
>
> deploy should belong to the `build` scope`, so suggest using the `build`
> instead `deploy`.
>
>
> tison  于2022年8月19日周五 17:46写道：
>
> > BTW, how can I sort changes for the metadata store?
> >
> > Best,
> > tison.
> >
> >
> > tison  于2022年8月19日周五 17:44写道：
> >
> > > To proposal a workable solution, I suggest:
> > >
> > > replace
> > >
> > > * pkg
> > > * tool
> > > * deploy
> > > * ci
> > > * workflow
> > > * build
> > >
> > > with
> > >
> > > * ci - CI workflow changes or debugging.
> > > * build - all things related to the build system, including tools,
> > > deployment logic, maven changes, packaging logics, docker image, build
> > > scripts.
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > tison  于2022年8月19日周五 17:41写道：
> > >
> > >> > I intended to mean changes to "process / standard / guide" [2]
> rather
> > >> than "CI workflow", but it still causes confusion.
> > >>
> > >> How can a PR be relevant to these things? I think the result should be
> > >> either CI workflow changes or document updates. We don't need a
> > dedicated
> > >> "workflow" in such situations.
> > >>
> > >> > build system or external dependencies.
> > >>
> > >> So, it overlaps with deps. While I can regard it as Maven/Docker/Build
> > >> script related changes, we may not have "pkg", "tool", "deploy" that
> can
> > >> overlap with this.
> > >>
> > >> Best,
> > >> tison.
> > >>
> > >>
> > >> tison  于2022年8月19日周五 17:38写道：
> > >>
> > >>> As for the type candidates:
> > >>>
> > >>> LGTM. No comment here.
> > >>>
> > >>> As for the scope candidates:
> > >>>
> > >>> +1 for dep -> deps
> > >>> +1 for fcn -> fn
> > >>>   Among most communities and language conventions, the abbr of
> function
> > >>> is fn (Rust), fun (Erlang), or func (Golang). No fcn IIRC. I'd prefer
> > the
> > >>> short one, fn.
> > >>> +1 for ts -> offloader
> > >>>   If I get it right, tiered storage is offloader. We can save one
> word
> > >>> while keeping semantic.
> > >>>
> > >>> I don't know clearly what is:
> > >>> * pkg
> > >>> * tool
> > >>> * deploy
> > >>> * ci
> > >>> * workflow
> > >>> * build
> > >>> They look quite similar or overlapping.
> > >>>
> > >>> Rest LGTM.
> > >>>
> > >>> As for the remaining issues:
> > >>>
> > >>> - Submit breaking changes
> > >>> [feat][broker]! Support xx
> > >>>
> > >>> This is fine. Since we don't verify what follows the [type][scope]
> > >>> section, it doesn't block the proposal.
> > >>>
> > >>> - Submit PIP changes
> > >>> [feat][broker] PIP-198: Support xx
> > >>>
> > >>> The same as before. Contributors can name whatever they like. We
> don't
> > >>> set too complex rules.
> > >>>
> > >>> - Cherry pick changes [4]
> > >>> Choice A: [fix][broker][branch-2.9] xxx
> > >>> Choice B: [fix][broker] xxx. And add "cherry pick xxx to branch-2.9"
> in
> > >>> the
> > >>> PR description.
> > >>>
> > >>> I'd prefer [fix][broker][BP-2.9] to save some letters. This is how
> the
> > >>> Flink community does. BP means backport. But yes, it's not a
> > requirement
> > >>> but a suggestion.
> > >>>
> > >>>
> > >>> Best,
> > >>> tison.
> > >>>
> > >>
> >
>

[Doc - Breaking Change] Follow New Steps to Update 2.8.x/2.9.x/2.10.x Docs

[Yu]

Hi team,


If you want to update docs for 2.8.x, 2.9.x, and 2.10.x, please follow the
new process here [1] since we manage multiple doc versions in a more
efficient way [2].


@momo-jun, @urfreespace, thanks for making this happen!


[1]
https://docs.google.com/document/d/1-1uJyd1k9_h56xiiVRVOnrLcCnTmg9n7SrHhNVNEEi4/edit#bookmark=id.q5m2r5pimdi6

[2] https://github.com/apache/pulsar/issues/16637


Yu

Re: [Discussion] PIP 78: Replace brodocs with docsify?

[Yu]

Thanks Dave!

> How is this search organized on the server and how would this integrate
with algolia?

Search is performed at the front end, and it does not need to integrate
with Algolia.

> Google Analytics will be disallowed on ASF project sites very soon due to
Privacy concerns with tracking data. I’ve warned about this several times.
Please eliminate GA. If we need to track then we have options.

Listing GA here just shows docsify's capabilities.
As we discussed before [1], GA will no longer process new data in standard
properties beginning July 1, 2023.
Matteo is being considered to replace it.

[1] https://github.com/apache/pulsar/issues/15664

Yu and signormercurio






On Thu, Aug 18, 2022 at 9:46 PM Dave Fisher  wrote:

>
>
> Sent from my iPhone
>
> > On Aug 18, 2022, at 4:55 AM, Yu  wrote:
> >
> > Hi team,
> >
> > To reduce manual work, we’re constantly implementing PIP 78: Generate
> Docs
> > from Code Automatically [1].
> >
> > Docs here refer to the following：
> > - Connector configurations [2]
> > - Client configurations [3]
> > - Pulsar CLI tools [4]
> > - Pulsar configurations [5]
> > - pulsar-admin [6]
> >
> > # Question
> >
> > Currently, some of the docs above [7] are generated using brodocs [8].
> > We’re wondering if it makes sense to replace brodocs with docsify?
> >
> > # docsify benefits
> >
> > ## For users
> > - Enjoy new features (eg. search, copy to clipboard, language
> highlighting,
> > tabs, Disqus, etc.)
>
> How is this search organized on the server and how would this integrate
> with algolia?
>
> > - More clear and organized layout
> >
> > ## For doc maintainers
> > - Simple and lightweight
> > - No statically built HTML files. Instead, it smartly loads and parses
> .md
> > files and displays them as a website.
> > - Allow feature customization
> > - Able to work with Google Analytics to track data
>
> Google Analytics will be disallowed on ASF project sites very soon due to
> Privacy concerns with tracking data. I’ve warned about this several times.
> Please eliminate GA. If we need to track then we have options.
>
> Also we never discuss GA anywhere within the PMC or developer community.
> What value does it have?
>
> Dave
>
> >
> > # Demo
> >
> > We’ve created a demo here [9].
> > This demo is only for demonstration purposes, so we just add a few
> > improvements. It can be iterated later.
> >
> > 
> >
> > If docsify is better, we’ll use it for all the docs above to provide a
> > consistent content experience.
> >
> > Feel free to check and comment, thank you!
> >
> > [1] https://lists.apache.org/thread/638q6kmq81z2qjmyhgkqzp00sllh4x0w
> > [2] https://pulsar.apache.org/docs/next/io-connectors (Configurations
> for
> > each connector)
> > [3] https://pulsar.apache.org/docs/next/client-libraries-java
> > (Configuration for each client. Here takes Java client as an example, it
> > refers to configurations of client, producer, consumer, and reader)
> > [4] https://pulsar.apache.org/docs/next/reference-cli-tools
> > [5] https://pulsar.apache.org/docs/next/reference-configuration
> > [6] https://pulsar.apache.org/tools/pulsar-admin/
> > [7] https://pulsar.apache.org/tools/
> > [8] https://github.com/Birdrock/brodocs
> > [9] https://pulsar.apache.org/tools/pulsar-config/2.11.0-SNAPSHOT/#/
> >
> > Yu, signormercurio, urfreespace
>
>

Re: [Discussion] PIP 198 - How to define [type] and [scope]?

[Yu]

Thanks, Zixuan!

> It should be the same thing. If I make a mistake, please tell me.

Sorry, I misunderstood it. I’ve removed the “rest” scope.



As we discussed just now, we reached consensuses on the following aspects:

- Use  “deps” to represent “dependency” since “dep” might be confused with
“deploy”.

- Use “sec” to represent “security”.



But we still have an issue:

How to define storage / tiered storage (scope)?

- Option 1: only create “storage” scope.
It contains all changes to storage (bookie, tiered storage, etc).

- Option 2: create both “storage” and “tiered storage” scopes.
Bookie changes go to “storage”.
Tiered storage changes go to “tiesto” (abbr. "ts" is not used since it
might be confused with TypeScript).

Hi developers, which do you prefer? Or any other suggestions? Thank you!

Yu

On Fri, Aug 19, 2022 at 5:01 PM Yu  wrote:

> Thanks, tison!
>
> > What's the difference between ci, workflow, and build?
>
> As explained in [Guide] Pulsar Pull Request Naming Convention [1],
>
> - ci:
> CI configuration files and scripts.
>
> - build:
> build system or external dependencies.
>
> - workflow:
> I intended to mean changes to "process / standard / guide" [2] rather than
> "CI workflow", but it still causes confusion.
> So I'm wondering if the word "workflow" should be changed to "process"? Or
> another more appropriate one?
> Previously, I did not categorize "process / standard / guide" to "misc"
> because I thought they are important and should be highlighted.
> But maybe we have to categorize it to "misc" if can not find a suitable
> word.
> Thoughts?
>
> > I make a change on checkstyle rules, which one should I sort it to?
> From the definition above, this belongs to "build", does it make sense?
>
> ~~
>
> Hi anyone else, feel free to comment, thank you!
>
> ~~
>
> [1]
> https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.skv7rjx6t1y0
>
> [2] Examples:
>
> - Update issue templates:
> [feat][workflow] Change doc issue template from markdown to yml,
> https://github.com/apache/pulsar/pull/13359
>
> - Update PR templates:
> [improve][workflow] Add PR guideline info to PR template,
> https://github.com/apache/pulsar/pull/15005
>
> - Add standards:
> [feature][workflow] Add Pulsar PR Naming Convention,
> https://github.com/apache/pulsar/pull/16055
>
> - Add guides:
> [feat][workflow] Add instructions for previewing website changes,
> https://github.com/apache/pulsar-site/pull/136
>
> ~~
>
> Yu
>
> On Thu, Aug 18, 2022 at 11:51 PM Zixuan Liu  wrote:
>
>> > Since here uses a singular noun, how about using "dep"?
>>
>> Sometimes we will update multiple dependencies so I want to use the
>> `deps`.
>>
>> > Are "security" and "tiered-storage" too long?
>>
>> Although the word is very long, it will look very clear.
>>
>> > "rest" here refers to client library REST [2]
>> And the "rest" you mentioned belongs to "admin", which includes
>> pulsar-admin, REST API, Java admin API [3]
>>
>> It should be the same thing. If I make a mistake please tell me.
>>
>> Thanks,
>> Zixuan
>>
>>
>> Yu  于2022年8月18日周四 16:45写道：
>>
>> > Thank you all!
>> >
>> > Hi Zixuan and all,
>> >
>> > > - dep (abbr for dependency) -> deps
>> > "dep" is abbr for "dependency"
>> > while "deps" can be abbr for "dependencies"
>> > Since here uses a singular noun, how about using "dep"?
>> >
>> > > - fcn (abbr for function) -> func
>> > +1
>> >
>> > > - sec (abbr for security) -> security
>> > > - ts (abbr for tiered storage) -> tiered-storage
>> > Are "security" and "tiered-storage" too long?
>> > - "sec" is commonly used in the science industry [1]
>> > - "ts" is suggested because you might know it refers to "tiered
>> storage" at
>> > first glance
>> > since there seems to be no similar Pulsar concept/terminology
>> > that uses the same abbreviation.
>> >
>> > - rest (changes to REST) -> Using the `admin` instead of rest?
>> > "rest" here refers to client library REST [2]
>> > And the "rest" you mentioned belongs to "admin", which includes
>> > pulsar-admin, REST API, Java adm

Re: [Discussion] PIP 198 - How to define [type] and [scope]?

[Yu]

Thanks, tison!

> What's the difference between ci, workflow, and build?

As explained in [Guide] Pulsar Pull Request Naming Convention [1],

- ci:
CI configuration files and scripts.

- build:
build system or external dependencies.

- workflow:
I intended to mean changes to "process / standard / guide" [2] rather than
"CI workflow", but it still causes confusion.
So I'm wondering if the word "workflow" should be changed to "process"? Or
another more appropriate one?
Previously, I did not categorize "process / standard / guide" to "misc"
because I thought they are important and should be highlighted.
But maybe we have to categorize it to "misc" if can not find a suitable
word.
Thoughts?

> I make a change on checkstyle rules, which one should I sort it to?
>From the definition above, this belongs to "build", does it make sense?

~~

Hi anyone else, feel free to comment, thank you!

~~

[1]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.skv7rjx6t1y0

[2] Examples:

- Update issue templates:
[feat][workflow] Change doc issue template from markdown to yml,
https://github.com/apache/pulsar/pull/13359

- Update PR templates:
[improve][workflow] Add PR guideline info to PR template,
https://github.com/apache/pulsar/pull/15005

- Add standards:
[feature][workflow] Add Pulsar PR Naming Convention,
https://github.com/apache/pulsar/pull/16055

- Add guides:
[feat][workflow] Add instructions for previewing website changes,
https://github.com/apache/pulsar-site/pull/136

~~

Yu

On Thu, Aug 18, 2022 at 11:51 PM Zixuan Liu  wrote:

> > Since here uses a singular noun, how about using "dep"?
>
> Sometimes we will update multiple dependencies so I want to use the `deps`.
>
> > Are "security" and "tiered-storage" too long?
>
> Although the word is very long, it will look very clear.
>
> > "rest" here refers to client library REST [2]
> And the "rest" you mentioned belongs to "admin", which includes
> pulsar-admin, REST API, Java admin API [3]
>
> It should be the same thing. If I make a mistake please tell me.
>
> Thanks,
> Zixuan
>
>
> Yu  于2022年8月18日周四 16:45写道：
>
> > Thank you all!
> >
> > Hi Zixuan and all,
> >
> > > - dep (abbr for dependency) -> deps
> > "dep" is abbr for "dependency"
> > while "deps" can be abbr for "dependencies"
> > Since here uses a singular noun, how about using "dep"?
> >
> > > - fcn (abbr for function) -> func
> > +1
> >
> > > - sec (abbr for security) -> security
> > > - ts (abbr for tiered storage) -> tiered-storage
> > Are "security" and "tiered-storage" too long?
> > - "sec" is commonly used in the science industry [1]
> > - "ts" is suggested because you might know it refers to "tiered storage"
> at
> > first glance
> > since there seems to be no similar Pulsar concept/terminology
> > that uses the same abbreviation.
> >
> > - rest (changes to REST) -> Using the `admin` instead of rest?
> > "rest" here refers to client library REST [2]
> > And the "rest" you mentioned belongs to "admin", which includes
> > pulsar-admin, REST API, Java admin API [3]
> >
> > - misc (abbr for miscellaneous) -> chore?
> > I'm OK with both choices.
> > Hi other developers, what's your preference on this?
> >
> > [1] https://www.abbreviations.com/abbreviation/Security
> > [2] https://pulsar.apache.org/docs/next/client-libraries-rest
> > [3]
> >
> >
> https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.nnekhkthmwlh
> >
> >
> > Yu
> >
> > On Thu, Aug 18, 2022 at 10:50 AM Zixuan Liu  wrote:
> >
> > > Thank yu for your work! Overall looks good to me, but I would like to
> > > request changes.
> > >
> > > I prefer:
> > >
> > > - dep (abbr for dependency) -> deps
> > > - fcn (abbr for function) -> func
> > > - sec (abbr for security) -> security
> > > - ts (abbr for tiered storage) -> tiered-storage
> > > - txn (abbr for transaction)
> > > - rest (changes to REST) -> Using the `admin` instead of rest?
> > > - misc (abbr for miscellaneous)  -> chore?
> > >
> > >
> > > > - Submit breaking changes
> > > > [feat][broker]! Support xx
> > >
> > > There should be no such behavior. When we ha

Re: [ANNOUNCE] Jiwei Guo as a new PMC member in Pulsar

[Yu]

Congrats Jiwei!

On Fri, Aug 19, 2022 at 10:45 AM Zixuan Liu  wrote:

> Congrats!
>
> Zixuan
>
> Jun M  于2022年8月19日周五 10:16写道：
>
> > Congrats to Jiwei!
> >
> >
> > Cheers,
> > Jun
> >
>

[Discussion] PIP 78: Replace brodocs with docsify?

[Yu]

Hi team,

To reduce manual work, we’re constantly implementing PIP 78: Generate Docs
from Code Automatically [1].

Docs here refer to the following：
- Connector configurations [2]
- Client configurations [3]
- Pulsar CLI tools [4]
- Pulsar configurations [5]
- pulsar-admin [6]

# Question

Currently, some of the docs above [7] are generated using brodocs [8].
We’re wondering if it makes sense to replace brodocs with docsify?

# docsify benefits

## For users
- Enjoy new features (eg. search, copy to clipboard, language highlighting,
tabs, Disqus, etc.)
- More clear and organized layout

## For doc maintainers
- Simple and lightweight
- No statically built HTML files. Instead, it smartly loads and parses .md
files and displays them as a website.
- Allow feature customization
- Able to work with Google Analytics to track data

# Demo

We’ve created a demo here [9].
This demo is only for demonstration purposes, so we just add a few
improvements. It can be iterated later.



If docsify is better, we’ll use it for all the docs above to provide a
consistent content experience.

Feel free to check and comment, thank you!

[1] https://lists.apache.org/thread/638q6kmq81z2qjmyhgkqzp00sllh4x0w
[2] https://pulsar.apache.org/docs/next/io-connectors (Configurations for
each connector)
[3] https://pulsar.apache.org/docs/next/client-libraries-java
(Configuration for each client. Here takes Java client as an example, it
refers to configurations of client, producer, consumer, and reader)
[4] https://pulsar.apache.org/docs/next/reference-cli-tools
[5] https://pulsar.apache.org/docs/next/reference-configuration
[6] https://pulsar.apache.org/tools/pulsar-admin/
[7] https://pulsar.apache.org/tools/
[8] https://github.com/Birdrock/brodocs
[9] https://pulsar.apache.org/tools/pulsar-config/2.11.0-SNAPSHOT/#/

Yu, signormercurio, urfreespace

Re: [Discussion] PIP 198 - How to define [type] and [scope]?

[Yu]

Thank you all!

Hi Zixuan and all,

> - dep (abbr for dependency) -> deps
"dep" is abbr for "dependency"
while "deps" can be abbr for "dependencies"
Since here uses a singular noun, how about using "dep"?

> - fcn (abbr for function) -> func
+1

> - sec (abbr for security) -> security
> - ts (abbr for tiered storage) -> tiered-storage
Are "security" and "tiered-storage" too long?
- "sec" is commonly used in the science industry [1]
- "ts" is suggested because you might know it refers to "tiered storage" at
first glance
since there seems to be no similar Pulsar concept/terminology
that uses the same abbreviation.

- rest (changes to REST) -> Using the `admin` instead of rest?
"rest" here refers to client library REST [2]
And the "rest" you mentioned belongs to "admin", which includes
pulsar-admin, REST API, Java admin API [3]

- misc (abbr for miscellaneous) -> chore?
I'm OK with both choices.
Hi other developers, what's your preference on this?

[1] https://www.abbreviations.com/abbreviation/Security
[2] https://pulsar.apache.org/docs/next/client-libraries-rest
[3]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.nnekhkthmwlh


Yu

On Thu, Aug 18, 2022 at 10:50 AM Zixuan Liu  wrote:

> Thank yu for your work! Overall looks good to me, but I would like to
> request changes.
>
> I prefer:
>
> - dep (abbr for dependency) -> deps
> - fcn (abbr for function) -> func
> - sec (abbr for security) -> security
> - ts (abbr for tiered storage) -> tiered-storage
> - txn (abbr for transaction)
> - rest (changes to REST) -> Using the `admin` instead of rest?
> - misc (abbr for miscellaneous)  -> chore?
>
>
> > - Submit breaking changes
> > [feat][broker]! Support xx
>
> There should be no such behavior. When we have the breaking changes we must
> make a PIP.
>
> > - Submit PIP changes
> > [feat][broker] PIP-198: Support xx
>
> Prefer [feat][broker][PIP-198] Support xx
>
>
> > - Cherry pick changes [4]
> > Choice A: [fix][broker][branch-2.9] xxx
> > Choice B: [fix][broker] xxx. And add "cherry pick xxx to branch-2.9" in
> the
> > PR description.
>
> I prefer choice A.
>
> Thanks,
> Zixuan
>
>
> Zike Yang  于2022年8月18日周四 08:43写道：
>
> > LGTM.
> >
> > > - Cherry pick changes [4]
> > > Choice A: [fix][broker][branch-2.9] xxx
> > > Choice B: [fix][broker] xxx. And add "cherry pick xxx to branch-2.9" in
> > the
> > > PR description.
> >
> > I prefer A.
> >
> > Thanks,
> > Zike Yang
> > Zike Yang
> >
> > On Wed, Aug 17, 2022 at 7:41 PM Qiang Huang 
> > wrote:
> > >
> > > Great work. I prefer "Choice A".
> > > > Cherry pick changes [4]
> > > > Choice A: [fix][broker][branch-2.9] xxx
> > >
> > > Yunze Xu  于2022年8月17日周三 18:32写道：
> > >
> > > > LGTM.
> > > >
> > > > Thanks,
> > > > Yunze
> > > >
> > > >
> > > >
> > > >
> > > > > 2022年8月17日 11:15，Yu  写道：
> > > > >
> > > > > Hi team,
> > > > >
> > > > > For PIP 198: Standardize PR Naming Convention using GitHub Actions
> > [1]
> > > > >
> > > > > How to define [type] and [scope]? Do these abbreviations LGTY?
> > > > >
> > > > > *[Guide] Pulsar Pull Request Naming Convention* [2] contains
> > everything
> > > > > about the definition. Feel free to check and comment!
> > > > >
> > > > > ~~
> > > > >
> > > > > TL;DR
> > > > >
> > > > > PR title format: [type][scope] Summary [3]
> > > > >
> > > > > ~~
> > > > >
> > > > > [type]
> > > > >
> > > > > 1. Definition: what actions do you take?
> > > > >
> > > > > 2. It must be one of the following:
> > > > > - feat (abbr for "feature")
> > > > > - improve
> > > > > - fix
> > > > > - cleanup
> > > > > - refactor
> > > > > - revert
> > > > >
> > > > > ~~
> > > > >
> > > > > [scope]
> > > > >
> > > > > 1. Definition: where do you make changes?
> > > > >
> > > > > 2. It must

[Discussion] PIP 198 - How to define [type] and [scope]?

[Yu]

Hi team,

For PIP 198: Standardize PR Naming Convention using GitHub Actions [1]

How to define [type] and [scope]? Do these abbreviations LGTY?

*[Guide] Pulsar Pull Request Naming Convention* [2] contains everything
about the definition. Feel free to check and comment!

~~

TL;DR

PR title format: [type][scope] Summary [3]

~~

[type]

1. Definition: what actions do you take?

2. It must be one of the following:
- feat (abbr for "feature")
- improve
- fix
- cleanup
- refactor
- revert

~~

[scope]

1. Definition: where do you make changes?

2. It must be one of the following:
- admin (changes to pulsar-admin, REST API, Java admin API)
- broker
- io
- deploy
- dep (abbr for dependency)
- fcn (abbr for function)
- monitor
- pkg (abbr for package)
- proxy
- schema
- sec (abbr for security)
- sql
- ts (abbr for tiered storage)
- tool
- txn (abbr for transaction)

- java (changes to Java client)
- cpp (changes to C++ client)
- py (changes to Python client)
- ws (changes to WebSocket)
- rest (changes to REST)

- test
- ci
- workflow
- build
- misc (abbr for miscellaneous)

- doc
- blog
- site (abbr for website)

~~

Besides, many developers have different opinions on the following aspects.
What's your writing preference?

- Submit breaking changes
[feat][broker]! Support xx

- Submit PIP changes
[feat][broker] PIP-198: Support xx

- Cherry pick changes [4]
Choice A: [fix][broker][branch-2.9] xxx
Choice B: [fix][broker] xxx. And add "cherry pick xxx to branch-2.9" in the
PR description.

~~

Feel free to comment and make your voice heard. Go vote! Thank you!

[1]
https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit
[2] https://lists.apache.org/thread/90rcjf1dv0fbkb5hm31kmgr65fj0nfnn
[3]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
[4]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=kix.849jztd92uk7

Yu

Re: [Discuss] PIP 198: Standardize PR Naming Convention using GitHub Actions

[Liu Yu]

Hi team

Thanks for your feedback!

Here is the voting result: 
Our existing convention (customized based on Angular) is chosen! 

~~

Our existing convention votes:
5, +1: Yu, Alex, Yunze, Jun, Qiang, 
1, +0: tison

Angular convention votes:
1, +1: tison

~~

I’ll close this discussion and initiate a discussion about another 
implementation detail in the next email.

Yu

On 2022/08/15 10:32:09 Yu wrote:
> Hi team,
> 
> Feel free to choose your desired convention **before EOD 8/16 (UTC +8)**.
> 
> We'll close this discussion and move to the next topic after that time.
> 
> Thank you!
> 
> Yu and mangoGoForward
> 
> On Mon, Aug 15, 2022 at 6:27 PM Yu  wrote:
> 
> > Hi tison,
> >
> > Thanks for your suggestions!
> >
> > > But following the Conventional Commits will ensure we can use the
> > toolchain
> > built around it, such as semantic release[1].
> >
> > Our customized convention can use the semantic release tool as well.
> >
> > > Also, Conventional Commits
> > have a standard to name a BREAKING CHANGE and a REVERT. We may or may not
> > want it later, shall we customize it further then?
> >
> > - BREAKING CHANGE: yes, we can customize it based on Conventional Commits,
> > eg, [feat][broker]! Add xxx
> > - REVERT: [revert] belongs to [type] in our rule [1]
> >
> > We can change it if it does not make sense.
> > I'll initiate an official discussion on these details and the definition
> > of [type][scope] in another independent email.
> >
> > [1]
> > https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
> >
> >
> > Yu and mangoGoForward
> >
> > On Mon, Aug 15, 2022 at 12:10 AM tison  wrote:
> >
> >> To clarify, I don't have a strong feeling about either convention.
> >> According to the reason above, I'd prefer the Angular convention, while +0
> >> for the customized convention.
> >>
> >> Best,
> >> tison.
> >>
> >>
> >> tison  于2022年8月14日周日 23:40写道：
> >>
> >> > Technically, the regexp of both conventions are:
> >> >
> >> > * Angular convention - /^(\w*)(?:\((.*)\))?!?: (.*)$/
> >> > * Customized conventions - /^\[(\w*)\](?:\[(.*)\])?: (.*)$/
> >> >
> >> > So, there're technically equal from the customized convention
> >> perspective,
> >> > or the Angular convention contains all expressiveness of the customized
> >> one.
> >> >
> >> > > It makes PR titles more clear and self-explanatory.
> >> > It's subjective. As described above, the Angular convention contains all
> >> > expressiveness of the customized one - it also has type and scope, and
> >> > delimiter length is almost the same.
> >> >
> >> > Let's think of the adoption of each convention:
> >> >
> >> > 1. Customized conventions: better to follow for developers who already
> >> use
> >> > it.
> >> > 2. Angular convention is a popular standard so that:
> >> >   (1) It's well-known by _new_ developers. Just tell them we are using
> >> > Conventional Commits.
> >> >   (2) Better toolchain support. This time we're lucky
> >> > that action-semantic-pull-request allows you to customize headerPattern.
> >> > But following the Conventional Commits will ensure we can use the
> >> toolchain
> >> > built around it, such as semantic release[1]. Also, Conventional Commits
> >> > have a standard to name a BREAKING CHANGE and a REVERT. We may or may
> >> not
> >> > want it later, shall we customize it further then?
> >> >
> >> > +1 for Angular convention.
> >> >
> >> > Best,
> >> > tison.
> >> >
> >> > [1] https://github.com/semantic-release/semantic-release
> >> >
> >> >
> >> > Qiang Huang  于2022年8月14日周日 12:15写道：
> >> >
> >> >> I agree that the customized one is better. +1  on the customized one.
> >> >>
> >> >> Jun M  于2022年8月12日周五 10:51写道：
> >> >>
> >> >> > +1 on the customized one.
> >> >> >
> >> >> >
> >> >> > Cheers
> >> >> > momo-jun
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> BR,
> >> >> Qiang Huang
> >> >>
> >> >
> >>
> >
> 

Re: [Discuss] PIP 198: Standardize PR Naming Convention using GitHub Actions

[Yu]

Hi team,

Feel free to choose your desired convention **before EOD 8/16 (UTC +8)**.

We'll close this discussion and move to the next topic after that time.

Thank you!

Yu and mangoGoForward

On Mon, Aug 15, 2022 at 6:27 PM Yu  wrote:

> Hi tison,
>
> Thanks for your suggestions!
>
> > But following the Conventional Commits will ensure we can use the
> toolchain
> built around it, such as semantic release[1].
>
> Our customized convention can use the semantic release tool as well.
>
> > Also, Conventional Commits
> have a standard to name a BREAKING CHANGE and a REVERT. We may or may not
> want it later, shall we customize it further then?
>
> - BREAKING CHANGE: yes, we can customize it based on Conventional Commits,
> eg, [feat][broker]! Add xxx
> - REVERT: [revert] belongs to [type] in our rule [1]
>
> We can change it if it does not make sense.
> I'll initiate an official discussion on these details and the definition
> of [type][scope] in another independent email.
>
> [1]
> https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
>
>
> Yu and mangoGoForward
>
> On Mon, Aug 15, 2022 at 12:10 AM tison  wrote:
>
>> To clarify, I don't have a strong feeling about either convention.
>> According to the reason above, I'd prefer the Angular convention, while +0
>> for the customized convention.
>>
>> Best,
>> tison.
>>
>>
>> tison  于2022年8月14日周日 23:40写道：
>>
>> > Technically, the regexp of both conventions are:
>> >
>> > * Angular convention - /^(\w*)(?:\((.*)\))?!?: (.*)$/
>> > * Customized conventions - /^\[(\w*)\](?:\[(.*)\])?: (.*)$/
>> >
>> > So, there're technically equal from the customized convention
>> perspective,
>> > or the Angular convention contains all expressiveness of the customized
>> one.
>> >
>> > > It makes PR titles more clear and self-explanatory.
>> > It's subjective. As described above, the Angular convention contains all
>> > expressiveness of the customized one - it also has type and scope, and
>> > delimiter length is almost the same.
>> >
>> > Let's think of the adoption of each convention:
>> >
>> > 1. Customized conventions: better to follow for developers who already
>> use
>> > it.
>> > 2. Angular convention is a popular standard so that:
>> >   (1) It's well-known by _new_ developers. Just tell them we are using
>> > Conventional Commits.
>> >   (2) Better toolchain support. This time we're lucky
>> > that action-semantic-pull-request allows you to customize headerPattern.
>> > But following the Conventional Commits will ensure we can use the
>> toolchain
>> > built around it, such as semantic release[1]. Also, Conventional Commits
>> > have a standard to name a BREAKING CHANGE and a REVERT. We may or may
>> not
>> > want it later, shall we customize it further then?
>> >
>> > +1 for Angular convention.
>> >
>> > Best,
>> > tison.
>> >
>> > [1] https://github.com/semantic-release/semantic-release
>> >
>> >
>> > Qiang Huang  于2022年8月14日周日 12:15写道：
>> >
>> >> I agree that the customized one is better. +1  on the customized one.
>> >>
>> >> Jun M  于2022年8月12日周五 10:51写道：
>> >>
>> >> > +1 on the customized one.
>> >> >
>> >> >
>> >> > Cheers
>> >> > momo-jun
>> >> >
>> >> >
>> >>
>> >> --
>> >> BR,
>> >> Qiang Huang
>> >>
>> >
>>
>

Re: [Discuss] PIP 198: Standardize PR Naming Convention using GitHub Actions

[Yu]

Hi tison,

Thanks for your suggestions!

> But following the Conventional Commits will ensure we can use the
toolchain
built around it, such as semantic release[1].

Our customized convention can use the semantic release tool as well.

> Also, Conventional Commits
have a standard to name a BREAKING CHANGE and a REVERT. We may or may not
want it later, shall we customize it further then?

- BREAKING CHANGE: yes, we can customize it based on Conventional Commits,
eg, [feat][broker]! Add xxx
- REVERT: [revert] belongs to [type] in our rule [1]

We can change it if it does not make sense.
I'll initiate an official discussion on these details and the definition of
[type][scope] in another independent email.

[1]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno


Yu and mangoGoForward

On Mon, Aug 15, 2022 at 12:10 AM tison  wrote:

> To clarify, I don't have a strong feeling about either convention.
> According to the reason above, I'd prefer the Angular convention, while +0
> for the customized convention.
>
> Best,
> tison.
>
>
> tison  于2022年8月14日周日 23:40写道：
>
> > Technically, the regexp of both conventions are:
> >
> > * Angular convention - /^(\w*)(?:\((.*)\))?!?: (.*)$/
> > * Customized conventions - /^\[(\w*)\](?:\[(.*)\])?: (.*)$/
> >
> > So, there're technically equal from the customized convention
> perspective,
> > or the Angular convention contains all expressiveness of the customized
> one.
> >
> > > It makes PR titles more clear and self-explanatory.
> > It's subjective. As described above, the Angular convention contains all
> > expressiveness of the customized one - it also has type and scope, and
> > delimiter length is almost the same.
> >
> > Let's think of the adoption of each convention:
> >
> > 1. Customized conventions: better to follow for developers who already
> use
> > it.
> > 2. Angular convention is a popular standard so that:
> >   (1) It's well-known by _new_ developers. Just tell them we are using
> > Conventional Commits.
> >   (2) Better toolchain support. This time we're lucky
> > that action-semantic-pull-request allows you to customize headerPattern.
> > But following the Conventional Commits will ensure we can use the
> toolchain
> > built around it, such as semantic release[1]. Also, Conventional Commits
> > have a standard to name a BREAKING CHANGE and a REVERT. We may or may not
> > want it later, shall we customize it further then?
> >
> > +1 for Angular convention.
> >
> > Best,
> > tison.
> >
> > [1] https://github.com/semantic-release/semantic-release
> >
> >
> > Qiang Huang  于2022年8月14日周日 12:15写道：
> >
> >> I agree that the customized one is better. +1  on the customized one.
> >>
> >> Jun M  于2022年8月12日周五 10:51写道：
> >>
> >> > +1 on the customized one.
> >> >
> >> >
> >> > Cheers
> >> > momo-jun
> >> >
> >> >
> >>
> >> --
> >> BR,
> >> Qiang Huang
> >>
> >
>

[Discuss] PIP 198: Standardize PR Naming Convention using GitHub Actions

[Yu]

Hi team,

For PIP 198: Standardize PR Naming Convention using GitHub Actions [1], we've
got many different suggestions on implementation details. Let's discuss
them one by one.

 Discussion topic:

For PR titles, which convention should we follow?
- Angular convention [2] - Our existing convention (it's customized based
on Angular) [3]  The differences between Angular and ours
are: 1. Definition 1.1 Property - Angular: [type] is required, [scope] is
optional - Ours: [type] and [scope] are required 1.2 Content - Angular: ci,
test, and docs belong to [type] - Ours: ci, test, and docs belong to
[scope] because
I think [type] defines "what action do you make" (eg.
add/delete/update/...),
while [scope] defines "where do you make changes". 2. Punctuation -
Angular: parenthesis and exclaim points are used - Ours: brackets are used
 Comparison examples Taking existing Pulsar PR titles as
examples: Example 1 - Angular: fix: Filter out already deleted entries
again before sending messages to consumers - Ours: [fix][broker] Filter out
already deleted entries again before sending messages to consumers Example
2 - Angular: ci: add flaky test issues and PRs to flaky test project -
Ours: [feat][ci] Add flaky test issues and PRs to flaky test project
Example 3 - Angular: docs: Document configuration added by PIP-145 doc -
Ours: [improve][doc] Document configuration added by PIP-145 doc
 I prefer our customized convention because: - It makes PR
titles more clear and self-explanatory. - No need to change users' habits
since many people in the community have followed and gotten used to it for
several months [4].  Feel free to comment. Thank you!
[1]
https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1

[2]
https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit-message-header
[3]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
[4] https://github.com/apache/pulsar/pulls

Yu, Max, mangoGoForward

[RESULT][VOTE] PIP 198: Standardize PR Naming Convention using GitHub Actions

[Yu]

Hi team, Thanks for all your suggestions! I'll move PIP 198 forward since
we get 3 binding votes (Penghui, Lari, Michael) [1].

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

Yu

Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions

[Yu]

Hi team,

This is a continued thread from the last one.

Feel free to vote and comment on this issue, thank you!



Vote:

For PR titles, which convention should we follow?

- Angular convention [1]
- Our customized convention (it's customized based on Angular) [2]



The differences between Angular and ours are:

1. Definition

1.1 Property
- Angular: [type] is required, [scope] is optional
- Ours: [type] and [scope] are required

1.2 Content
- Angular: ci, test, and docs belong to [type]
- Ours: ci, test, and docs belong to [scope] because I think [type] defines
"what action do you make" (eg. add/delete/update/...), while [scope]
defines "where do you make changes".

2. Punctuation

- Angular: parenthesis and exclaim points are used
- Ours: brackets are used



Comparison examples

Taking existing Pulsar PR titles as examples:

Example 1
- Angular:
fix: Filter out already deleted entries again before sending messages to
consumers
- Ours:
[fix][broker] Filter out already deleted entries again before sending
messages to consumers

Example 2
- Angular:
ci: add flaky test issues and PRs to flaky test project
- Ours:
[feat][ci] Add flaky test issues and PRs to flaky test project

Example 3
- Angular:
docs: Document configuration added by PIP-145  doc
- Ours:
[improve][doc] Document configuration added by PIP-145  doc



I prefer our customized convention because:

- It makes PR titles more clear and self-explanatory.

- No need to change users' habits since many people in the community have
followed and gotten used to it for several months [3].



Thoughts? Thank you!

[1]
https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit-message-header
[2]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
[3] https://github.com/apache/pulsar/pulls


On Wed, Aug 10, 2022 at 6:11 PM Yu  wrote:

>
> Hi team,
>
> Thanks for all your suggestions!
>
> I'll move PIP 198 forward since we get 3 binding votes (Penghui, Lari,
> Michael).
>
> For the implementation details, I've got many different suggestions, which
> can be summarized into 2 major issues:
>
> - Issue 1: which convention should we follow?
> Angular [1] or our existing one (customized based on Angular) [2]?
>
> - Issue 2: how to define [type] and [scope]?
> For example, abbreviations.
>
> To avoid chaos and personal bias, I'll initiate polls one by one and let
> the community decide.
>
> Once we reach a consensus on issue 1, we can move forward to issue 2.
>
> [1]
> https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit-message-header
> [2]
> https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
>
> Yu
>
> On Wed, Aug 10, 2022 at 6:05 PM Yu  wrote:
>
>> Hi Lari,
>>
>> Thanks for your suggestions! Please see my replies inline.
>>
>> > Would it be possible to improve the proposal in a way that the valid
>> prefixes for type and component are in a file in the repository and the
>> possible checker would use this file as the source of truth?
>>
>> Yes, it's the same as we did previously [1].
>>
>> > I hope we could get rid of the brackets too and simply use a similar
>> format as Angular does.
>>
>> I agree that the PR title should be as much concise as possible, but I
>> prefer our customized convention because:
>>
>> (1) Compared with our current convention (customized based on Angular)
>> [2], seems that Angular only saves one char.
>>
>> For example,
>>
>> - Angular: feat(broker): add xxx  → (): occupy 3 chars
>> - Ours: [feat][broker] add xxx → (): occupy 4 chars
>>
>> (2) I agree with Michael. Brackets make info clearer.
>>
>> Yu
>>
>> [1]
>> https://github.com/apache/pulsar/pull/16836/files#diff-30f66e07c98171a7ed7bd1f1f873a2dbfb05da069ec859af82dd6bc05048c2c5
>> [2]
>> https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
>>
>> On Tue, Aug 9, 2022 at 5:47 PM Lari Hotari  wrote:
>>
>>> +1, with some conditions about the details of PIP 198 that are listed
>>> below:
>>>
>>> Would it be possible to improve the proposal in a way that the valid
>>> prefixes for type and component are in a file in the repository and the
>>> possible checker would use this file as the source of truth? Tison already
>>> pointed out in a Slack discussion that such a GHA exists which uses a yaml
>>> file.
>>>
>>> I also hope that the prefixes are as short as possible since there'

Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions

[Yu]

Hi team,

Thanks for all your suggestions!

I'll move PIP 198 forward since we get 3 binding votes (Penghui, Lari,
Michael).

For the implementation details, I've got many different suggestions, which
can be summarized into 2 major issues:

- Issue 1: which convention should we follow?
Angular [1] or our existing one (customized based on Angular) [2]?

- Issue 2: how to define [type] and [scope]?
For example, abbreviations.

To avoid chaos and personal bias, I'll initiate polls one by one and let
the community decide.

Once we reach a consensus on issue 1, we can move forward to issue 2.

[1]
https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit-message-header
[2]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno

Yu

On Wed, Aug 10, 2022 at 6:05 PM Yu  wrote:

> Hi Lari,
>
> Thanks for your suggestions! Please see my replies inline.
>
> > Would it be possible to improve the proposal in a way that the valid
> prefixes for type and component are in a file in the repository and the
> possible checker would use this file as the source of truth?
>
> Yes, it's the same as we did previously [1].
>
> > I hope we could get rid of the brackets too and simply use a similar
> format as Angular does.
>
> I agree that the PR title should be as much concise as possible, but I
> prefer our customized convention because:
>
> (1) Compared with our current convention (customized based on Angular)
> [2], seems that Angular only saves one char.
>
> For example,
>
> - Angular: feat(broker): add xxx  → (): occupy 3 chars
> - Ours: [feat][broker] add xxx → (): occupy 4 chars
>
> (2) I agree with Michael. Brackets make info clearer.
>
> Yu
>
> [1]
> https://github.com/apache/pulsar/pull/16836/files#diff-30f66e07c98171a7ed7bd1f1f873a2dbfb05da069ec859af82dd6bc05048c2c5
> [2]
> https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
>
> On Tue, Aug 9, 2022 at 5:47 PM Lari Hotari  wrote:
>
>> +1, with some conditions about the details of PIP 198 that are listed
>> below:
>>
>> Would it be possible to improve the proposal in a way that the valid
>> prefixes for type and component are in a file in the repository and the
>> possible checker would use this file as the source of truth? Tison already
>> pointed out in a Slack discussion that such a GHA exists which uses a yaml
>> file.
>>
>> I also hope that the prefixes are as short as possible since there's a
>> general recommendation to keep a commit title under 50 characters as I have
>> explained in
>> https://lists.apache.org/thread/67fqbo25oq75wrpsq5s4xw9rr55mlbms . I
>> know it's not a hard limit, but it does harm readability of the commit log
>> in many tools if prefixes use up a majority of the title length.
>>
>> So as long as the prefixes are short and easy, I'm fine with this
>> proposal.
>>
>> I would have hoped that the proposal would have been more like the
>> Angular commit message format,
>> https://github.com/angular/angular/blob/main/CONTRIBUTING.md#-commit-message-format
>> . I like the short prefixes and how the "component" is "scope" and maps to
>> a npm module.
>>
>> In our case, the scope (we are calling this "component") could map
>> directly to the Maven artifactId by droping the "pulsar-" prefix. That
>> would prevent making up new names for the components that are different
>> from existing names.
>> for example: artifactId: pulsar-broker, use "broker"
>> artifactId: pulsar-io-kafke, use "io-kafka"
>> There would be some exceptions in the apache/pulsar repository for the
>> cpp client. That could be client-cpp (from directory name
>> "pulsar-client-cpp" by dropping the "pulsar-" prefix).
>>
>> Another concern that I had was about duplicating the information with
>> labels. Tison explained to my that the automation could add the labels
>> based on the title and the user wouldn't have to add duplicate information
>> if such a solution exists.
>>
>> Summary:
>> I hope that PIP 198 could be revisited with the proposed way to map the
>> component name directly from the Maven artifactId. Another request is to
>> shorten the type (use "feat" instead of "feature", etc.) to save
>> characters.
>> I hope we could get rid of the brackets too and simply use a similar
>> format as Angular does.
>>
>> -Lari
>>
>> On 2022/08/04 08:12:21 Yu wrote:
>> > Hi team,
>> >
>> > It has been

Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions

[Yu]

Hi Lari,

Thanks for your suggestions! Please see my replies inline.

> Would it be possible to improve the proposal in a way that the valid
prefixes for type and component are in a file in the repository and the
possible checker would use this file as the source of truth?

Yes, it's the same as we did previously [1].

> I hope we could get rid of the brackets too and simply use a similar
format as Angular does.

I agree that the PR title should be as much concise as possible, but I
prefer our customized convention because:

(1) Compared with our current convention (customized based on Angular) [2],
seems that Angular only saves one char.

For example,

- Angular: feat(broker): add xxx  → (): occupy 3 chars
- Ours: [feat][broker] add xxx → (): occupy 4 chars

(2) I agree with Michael. Brackets make info clearer.

Yu

[1]
https://github.com/apache/pulsar/pull/16836/files#diff-30f66e07c98171a7ed7bd1f1f873a2dbfb05da069ec859af82dd6bc05048c2c5
[2]
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno

On Tue, Aug 9, 2022 at 5:47 PM Lari Hotari  wrote:

> +1, with some conditions about the details of PIP 198 that are listed
> below:
>
> Would it be possible to improve the proposal in a way that the valid
> prefixes for type and component are in a file in the repository and the
> possible checker would use this file as the source of truth? Tison already
> pointed out in a Slack discussion that such a GHA exists which uses a yaml
> file.
>
> I also hope that the prefixes are as short as possible since there's a
> general recommendation to keep a commit title under 50 characters as I have
> explained in
> https://lists.apache.org/thread/67fqbo25oq75wrpsq5s4xw9rr55mlbms . I know
> it's not a hard limit, but it does harm readability of the commit log in
> many tools if prefixes use up a majority of the title length.
>
> So as long as the prefixes are short and easy, I'm fine with this
> proposal.
>
> I would have hoped that the proposal would have been more like the Angular
> commit message format,
> https://github.com/angular/angular/blob/main/CONTRIBUTING.md#-commit-message-format
> . I like the short prefixes and how the "component" is "scope" and maps to
> a npm module.
>
> In our case, the scope (we are calling this "component") could map
> directly to the Maven artifactId by droping the "pulsar-" prefix. That
> would prevent making up new names for the components that are different
> from existing names.
> for example: artifactId: pulsar-broker, use "broker"
> artifactId: pulsar-io-kafke, use "io-kafka"
> There would be some exceptions in the apache/pulsar repository for the cpp
> client. That could be client-cpp (from directory name "pulsar-client-cpp"
> by dropping the "pulsar-" prefix).
>
> Another concern that I had was about duplicating the information with
> labels. Tison explained to my that the automation could add the labels
> based on the title and the user wouldn't have to add duplicate information
> if such a solution exists.
>
> Summary:
> I hope that PIP 198 could be revisited with the proposed way to map the
> component name directly from the Maven artifactId. Another request is to
> shorten the type (use "feat" instead of "feature", etc.) to save
> characters.
> I hope we could get rid of the brackets too and simply use a similar
> format as Angular does.
>
> -Lari
>
> On 2022/08/04 08:12:21 Yu wrote:
> > Hi team,
> >
> > It has been 4 months since we discussed the [Guideline] Pulsar PR Naming
> > Convention [1].
> >
> > Nowadays, when reading the PR list [2], you’ll find more and more people
> > follow and get used to this rule.
> >
> > It improves collaboration efficiency, that is great!
> >
> > This makes us think about moving the rule forward, that is, standardizing
> > PR title naming using GitHub Actions, which is a more efficient way.
> >
> > So we'd like to start a vote on PIP 198: Standardize PR Naming Convention
> > using GitHub Actions [3].
> >
> >
> > This proposal contains:
> >
> > - Why do this?
> >
> > - How do this?
> >
> > - Pre-discussions and other thoughts
> >
> > Feel free to comment, thank you!
> >
> > [1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
> >
> > [2] https://github.com/apache/pulsar/pulls
> >
> > [3]
> >
> https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
> >
> >
> > Yu, Max, mangoGoForward
> >
>

Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions

[Liu Yu]

Hi tison,

Thanks for your suggestions! 

> Currently, I'd suggest: feature -> feat workflow -> ci improve/cleanup -> 
> chore...

I agree on some and will send votes step by step to let the community decide.

On 2022/08/09 09:21:54 tison wrote:
> Hi Yu,
> 
> To be clear, the candidates of types and components are a bit long which
> may waste space for meaningful information.
> 
> For example, Angular names feature as feat to save letters. GitHub only
> shows the first 50 characters for PR title.
> 
> I'd like to confirm that the name of types and components are not voted in
> this thread and postponed when we review the patch.
> 
> Currently, I'd suggest:
> 
> feature -> feat
> workflow -> ci
> improve/cleanup -> chore
> dependency -> dep
> function -> fn
> security -> sec
> website -> site
> ...
> 
> Best,
> tison.
> 
> 
> Qiang Huang  于2022年8月9日周二 15:07写道：
> 
> > +1 (non-binding) I like the idea of check PR title as a job.
> > Good job, Yu.
> >
> > tison  于2022年8月8日周一 22:07写道：
> >
> > > +1 (non-binding) to the proposal itself.
> > >
> > > Although, we should later move the standard to our website where the
> > whole
> > > project can easily contribute to and follow the general contribution
> > > process - that is, send a pull request, review, and merge. I regard
> > current
> > > gdoc content as a temporary container for this content.
> > >
> > > If this proposal gets accepted, @Yu you can create an issue for the dev
> > doc
> > > part and ping me. I can offer my help to write so.
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > Zike Yang  于2022年8月8日周一 13:35写道：
> > >
> > > > +1 (non-binding)
> > > >
> > > > Thanks
> > > > Zike Yang
> > > >
> > > > On Mon, Aug 8, 2022 at 1:06 PM Xiangying Meng 
> > > > wrote:
> > > > >
> > > > > +1(non-binding)
> > > > >
> > > > > yours sincerely,
> > > > > xiangying Meng
> > > > >
> > > > > On Thu, Aug 4, 2022 at 4:13 PM Yu  wrote:
> > > > >
> > > > > > Hi team,
> > > > > >
> > > > > > It has been 4 months since we discussed the [Guideline] Pulsar PR
> > > > Naming
> > > > > > Convention [1].
> > > > > >
> > > > > > Nowadays, when reading the PR list [2], you’ll find more and more
> > > > people
> > > > > > follow and get used to this rule.
> > > > > >
> > > > > > It improves collaboration efficiency, that is great!
> > > > > >
> > > > > > This makes us think about moving the rule forward, that is,
> > > > standardizing
> > > > > > PR title naming using GitHub Actions, which is a more efficient
> > way.
> > > > > >
> > > > > > So we'd like to start a vote on PIP 198: Standardize PR Naming
> > > > Convention
> > > > > > using GitHub Actions [3].
> > > > > >
> > > > > >
> > > > > > This proposal contains:
> > > > > >
> > > > > > - Why do this?
> > > > > >
> > > > > > - How do this?
> > > > > >
> > > > > > - Pre-discussions and other thoughts
> > > > > >
> > > > > > Feel free to comment, thank you!
> > > > > >
> > > > > > [1]
> > https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
> > > > > >
> > > > > > [2] https://github.com/apache/pulsar/pulls
> > > > > >
> > > > > > [3]
> > > > > >
> > > > > >
> > > >
> > >
> > https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
> > > > > >
> > > > > >
> > > > > > Yu, Max, mangoGoForward
> > > > > >
> > > >
> > >
> >
> >
> > --
> > BR,
> > Qiang Huang
> >
> 

Re: [Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions

[Liu Yu]

Hi tison,

Thanks for your suggestions! 

> Although, we should later move the standard to our website where the whole 
> project can easily contribute to ...

Sure. I'll move the [Guide] Pulsar Pull Request Naming Convention [1] to a 
public place where everyone can contribute after we finalize the content. 
Google doc is only for convenient editing.

[1] 
https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#heading=h.wu6ygjne8e35


On 2022/08/08 14:06:59 tison wrote:
> +1 (non-binding) to the proposal itself.
> 
> Although, we should later move the standard to our website where the whole
> project can easily contribute to and follow the general contribution
> process - that is, send a pull request, review, and merge. I regard current
> gdoc content as a temporary container for this content.
> 
> If this proposal gets accepted, @Yu you can create an issue for the dev doc
> part and ping me. I can offer my help to write so.
> 
> Best,
> tison.
> 
> 
> Zike Yang  于2022年8月8日周一 13:35写道：
> 
> > +1 (non-binding)
> >
> > Thanks
> > Zike Yang
> >
> > On Mon, Aug 8, 2022 at 1:06 PM Xiangying Meng 
> > wrote:
> > >
> > > +1(non-binding)
> > >
> > > yours sincerely,
> > > xiangying Meng
> > >
> > > On Thu, Aug 4, 2022 at 4:13 PM Yu  wrote:
> > >
> > > > Hi team,
> > > >
> > > > It has been 4 months since we discussed the [Guideline] Pulsar PR
> > Naming
> > > > Convention [1].
> > > >
> > > > Nowadays, when reading the PR list [2], you’ll find more and more
> > people
> > > > follow and get used to this rule.
> > > >
> > > > It improves collaboration efficiency, that is great!
> > > >
> > > > This makes us think about moving the rule forward, that is,
> > standardizing
> > > > PR title naming using GitHub Actions, which is a more efficient way.
> > > >
> > > > So we'd like to start a vote on PIP 198: Standardize PR Naming
> > Convention
> > > > using GitHub Actions [3].
> > > >
> > > >
> > > > This proposal contains:
> > > >
> > > > - Why do this?
> > > >
> > > > - How do this?
> > > >
> > > > - Pre-discussions and other thoughts
> > > >
> > > > Feel free to comment, thank you!
> > > >
> > > > [1] https://lists.apache.org/thread/sk9ops3t94jmzc5tndk08y9khf7pj6so
> > > >
> > > > [2] https://github.com/apache/pulsar/pulls
> > > >
> > > > [3]
> > > >
> > > >
> > https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#
> > > >
> > > >
> > > > Yu, Max, mangoGoForward
> > > >
> >
> 

[New Doc] Language support of pulsar-admin functions subcommands is shown

[Yu]

Hi team,

A good news:


Now, language support (Java, Python, Go) of pulsar-admin functions
subcommands (creat, localrun, update) is shown on the Pulsar API doc page.
[1]


This doc is generated from code automatically. If you update descriptions
in source code files, feel free to ask me to review them from the technical
writing perspective.


Besides, welcome to update this matrix [2] if you submit changes to the
function and client.





Special thanks to @signormercurio for making this happen! [3]


And thanks for your technical support!

@urfreespace, @freeznet, @jiangpengcheng, @laminar*, @*danpi


[1] https://pulsar.apache.org/tools/pulsar-admin/2.11.0-SNAPSHOT/#functions

[2]
https://docs.google.com/spreadsheets/d/1YHYTkIXR8-Ql103u-IMI18TXLlGStK8uJjDsOOA0T20/edit#gid=1784579914


[3] https://github.com/apache/pulsar/pull/16853


Yu

[Vote] PIP 198: Standardize PR Naming Convention using GitHub Actions

[Yu]

Hi team,

It has been 4 months since we discussed the [Guideline] Pulsar PR Naming
Convention [1].

Nowadays, when reading the PR list [2], you’ll find more and more people
follow and get used to this rule.

It improves collaboration efficiency, that is great!

This makes us think about moving the rule forward, that is, standardizing
PR title naming using GitHub Actions, which is a more efficient way.

So we'd like to start a vote on PIP 198: Standardize PR Naming Convention
using GitHub Actions [3].


This proposal contains:

- Why do this?

- How do this?

- Pre-discussions and other thoughts

Feel free to comment, thank you!

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

[2] https://github.com/apache/pulsar/pulls

[3]
https://docs.google.com/document/d/1sJlUNAHnYAbvu9UtEgCrn_oVTnVc1M5nHC19x1bFab4/edit?pli=1#


Yu, Max, mangoGoForward

Re: [Guideline] Pulsar PR Naming Convention

[Yu]

Hi Zixuan and Tison,

Thanks for your comments!
We're considering your suggestion and will turn the proposal into a PIP and
call a vote.

Yu, Max, mangoGoForward

On Mon, Aug 1, 2022 at 4:29 PM Zixuan Liu  wrote:

> Hi Yu,
>
> This is a good idea, I noticed this thread for a long time.
>
> This PR title looks like convention message[1], it should be variant. If
> we use the convention message, we can focus on other things, and reduce
> time on these tools, but the developer gets used to the current standard.
> If we don't consider these, I suggest using the convention message.
>
> Currently we have a draft PR[2] to check the PR title, I think we should
> make a dev guide to explain this format on Pulsar repository, then continue
> to start this PR.
>
>
> [1] https://www.conventionalcommits.org/en/v1.0.0/#summary
> [2] https://github.com/apache/pulsar/pull/16836
>
> Thanks,
> Zixuan
>
>
> On 2022/03/17 02:11:54 Yu wrote:
> > Hi Pulsarers,
> >
> > We submit or review PRs almost every day, we might see many vague and
> > unclear PR titles that decrease team efficiency and productivity.
> >
> > Good PR titles offer bring many benefits, such as speeding up the review
> > process and improving search efficiency.
> >
> > To solve the vague PR title issue and move *PIP 112: Generate Release
> Notes
> > Automatically* [1] forward, I've created *Guideline: Pulsar PR Naming
> > Convention* [2], which explains why you need good PR titles and how you
> do
> > that with various self-explanatory examples. Also, Pulsar and client
> > release notes will be generated automatically based on the rules defined
> in
> > this guide.
> >
> > Do not hesitate to comment if you have any questions or concerns.
> Feedback
> > before EOD 3/21 CST is highly appreciated, thanks!
> >
> > [1]
> >
> https://docs.google.com/document/d/1Ul2qIChDe8QDlDwJBICq1VviYZhdk1djKJJC5wXAGsI/edit#
> >
> > [2]
> >
> https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit#
> >
> > Regards,
> > Anonymitaet
> >

Re: [VOTE] PIP-190: Simplify Pulsar documentation release and maintenance strategy

[Yu]

+1 since it improves the efficiency of managing docs.

On Thu, Jul 28, 2022 at 8:16 AM M Jun  wrote:

> Hi, Pulsar community,
>
> I'd like to start a vote on PIP-190: Simplify Pulsar documentation release
> and maintenance strategy.
>
> You can find the proposal at https://github.com/apache/pulsar/issues/16637
> and the discussion thread at
> https://lists.apache.org/thread/g5b8lcwtn10ox7vd67n31om9w1rxn4l7.
>
> The vote will stay open for at least 48 hours.
>
>
> Cheers,
> momo-jun
>

Re: 回复: [Discuss] PIP-190: Simplify Pulsar documentation release and maintenance strategy

[Liu Yu]

+1 for this proposal since it improves the efficiency of managing docs.

We'll take it as we reach a lazy consensus and implement this plan if there is 
no objection until tomorrow.

On 2022/07/25 09:13:50 M Jun wrote:
> Hi Asaf,
> 
> The doc files for all older versions are independent copies, stored at 
> https://github.com/apache/pulsar/tree/master/site2/website/versioned_docs.
> 
> For example, the doc for 2.10.0 was a copy saved from the next (master) doc 
> at that milestone.
> 
> 发件人: Asaf Mesika 
> 发送时间: 2022年7月24日 21:00
> 收件人: dev@pulsar.apache.org 
> 主题: Re: [Discuss] PIP-190: Simplify Pulsar documentation release and 
> maintenance strategy
> 
> If I understand correctly, using tags, you can automatically create the
> docs for the next minor version?
> So for older minor versions, where those files will be at? using tags from
> git?
> 
> On Sat, Jul 23, 2022 at 7:04 AM Ma Jun  wrote:
> 
> > Hi, Pulsar community,
> >
> > Happy weekend!
> >
> > I'd like to open a discussion about PIP-190: Simplify Pulsar documentation
> > release and maintenance strategy.
> >
> > Proposal link: https://github.com/apache/pulsar/issues/16637.
> >
> >
> > -
> >
> > ## Motivation
> >
> > This proposal is focused on improving and simplifying the release and
> > maintenance strategy of the existing Apache Pulsar documentation.
> >
> > In general, this proposal provides equal values and a better user
> > experience without sacrificing unpredictable efforts in the release and
> > maintenance process. The benefits include:
> > * Improve user experience when they look for the documentation of a
> > specific release.
> > * Optimize the doc development and release process for bug-fix releases:
> >* Turn doc development for bug-fix releases from post-release into
> > just-in-time.
> >* Save Release Manager’s effort in generating doc files for bug-fix
> > releases.
> > * Save a great amount of the community’s effort in syncing doc
> > improvements and fixes to historical doc versions that are in the
> > maintenance cycle.
> >
> >
> > Since there are quite a few illustrations and links in this proposal, I
> > didn't copy and paste the complete content into this email thread. You can
> > access the GitHub link to review the proposal with a better view.
> >
> >
> > Cheers!
> >
> > momo-jun
> >
> >
> 

Re: [ANNOUNCE] Micheal Marshall as a new PMC member in Pulsar

[Yu]

Congrats Michael! Thanks for your contribution to the doc and website!

On Wed, Jul 27, 2022 at 12:46 AM Nicolò Boschi  wrote:

> Congrats! Very well deserved!!
>
> Nicolò Boschi
>
> Il Mar 26 Lug 2022, 18:26 Christophe Bornet  ha
> scritto:
>
> > Congratulations Michael ! Well deserved !
> >
> > Le mar. 26 juil. 2022 à 17:22, Enrico Olivelli  a
> > écrit :
> >
> > > I am glad to announce that the Apache Pulsar PMC invited Micheal to
> > > join the PMC and he accepted.
> > >
> > > Micheal is doing a great job in stewarding our community
> > >
> > > Please join me and celebrate !
> > >
> > > Enrico Olivelli
> > >
> >
>

[Announcement] Pulsar Summit 2022 is coming soon!

[Yu]

Hi team,

The Pulsar Summit 2022 will be held on August 18th at Hotel Nikko in San
Francisco.

This action-packed, one-day event will include amazing sessions with
speakers from AWS, Klaviyo, Ververica, OneHouse, Nomura, the Apache Pulsar
PMC members, and more! Find the full agenda here [1].

In addition to amazing speakers and content, there will be a ton of
networking opportunities.

This is the first-ever in-person Pulsar Summit in North America. It's a
great opportunity to connect with the community and to learn the latest in
real-time data streaming.

Don't miss this chance to be part of the great event! Save your spot today!

Best,
Yu

[1] https://pulsar-summit.org/event/san-francisco-2022

Re: [VOTE] Enable GitHub Discussion for user-facing discussion

[Yu]

Hi tison, thanks for creating this vote!
I thought we reached a lay consensus since there was no objection since the
last discussion [1]

+1 for this proposal.
I've explained the reasons and showed the benefits previously [2]

[1] https://lists.apache.org/thread/1y7zbchlbokwnpd0jv2tt5jtzg6px6yn
[2] https://lists.apache.org/thread/83pst643h9cqcryo3zsjd240jmqzvn73

On Tue, Jul 12, 2022 at 6:01 PM tison  wrote:

> Hi,
>
> In the previous email[1] I started a discussion about enabling GitHub
> Discussions in apache/pulsar repository and we meet a consensus to avoid
> making development discussions truth happen on the sources. It's also a
> requirement of INFRA team[2]
>
> Apart of it, for user-facing discussions it's conventions for Pulsar users
> who have a GitHub account but are unfamiliar with mailing list to throw
> their use case and questions on GitHub discussion.
>
> Dave has opened and issue[2][3] and prepare the patch[4] for turning on the
> discussion option but obviously we still need an explicit consensus among
> the community and it's also required before INFRA team takes action.
>
> I'd like to start this voting thread for "Enable GitHub Discussion for
> user-facing discussion", please reply with your opinion:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Best,
> tison.
>
> [1] https://lists.apache.org/thread/1y7zbchlbokwnpd0jv2tt5jtzg6px6yn
> [2] https://issues.apache.org/jira/browse/INFRA-23477
> [3] https://github.com/apache/pulsar/issues/16275
> [4] https://github.com/apache/pulsar/pull/16528
>

Re: How to Show Info about Community?

[Yu]

Hi team,

Now we have a fresh "Community" page [1], which shows the Pulsar PMC list,
contributors over time, monthly active contributors, etc.

Thanks Wenqing for making this happen!

[1] https://pulsar.apache.org/community#section-community

Yu

On Tue, Jul 5, 2022 at 9:15 PM Yu  wrote:

> Hi tison, thanks for your info! We're researching SkyWalking's page and
> trying to create better designs.
>
> Hi team, we plan to show only PMC members and not show org if there is no
> objection.
>
> Yu and Wenqing
>
>
>
> On Mon, Jul 4, 2022 at 1:51 PM tison  wrote:
>
>> Hi Yu,
>>
>> Thanks for starting this discussion. Here are my two coins.
>>
>> 1. For showing membership, I suggest you take a look at SkyWalking's Team
>> page[1]. As the Pulsar ecosystem grows larger and larger, the framework
>> SkyWalking's Team page used is a good fit IMO.
>> 2. For organization affinity, I suggest we don't include them since it's
>> hard to maintain and in Apache we always play as individuals.
>>
>> Best,
>> tison.
>>
>> [1] https://skywalking.apache.org/team/
>>
>>
>> Yu  于2022年7月4日周一 12:35写道：
>>
>>> Hi team,
>>>
>>> We're updating [1] the "Meet the Community" info [2] since the current
>>> info
>>> is obsolete.
>>>
>>> Several questions on how to show the info:
>>>
>>> ==
>>>
>>> Q1: only show PMC members and add a tip?
>>>
>>> Context:
>>>
>>> a. Nowadays, we have more and more PMC members (30 in total) and
>>> committers
>>> (62 in total) while many of them are inactive.
>>>
>>> b. If we show them all, the list on the website would be very long as
>>> they
>>> are growing all the time.
>>>
>>> c. How about showing only PMC members and adding a tip?
>>> The tip can be: For the complete and up-to-date list of PMC members and
>>> committers, see [Apache Pulsar Committee](
>>> https://projects.apache.org/committee.html?pulsar).
>>>
>>> d. Similar cases are Cassandra [3] and Flink [4].
>>>
>>> ==
>>>
>>> Q2: show organizations or not?
>>>
>>> Context:
>>>
>>> a. `org` is in the team.js file [5]. Shall we show organizations on the
>>> Pulsar website?
>>>
>>> b.1 Showing
>>>
>>> - Pros: It demonstrates that Pulsar is a diverse community because
>>> people are
>>> from various organizations.
>>>
>>> - Cons: Organization info needs to be collected and added manually
>>>
>>> - Example: Spark [6]
>>>
>>> b.2 Not showing
>>>
>>> - Pros: people work as individuals to make contributions to Pulsar
>>> (weaken
>>> vendors)
>>>
>>> ==
>>>
>>> Feel free to comment, thank you!
>>>
>>> [1] https://github.com/apache/pulsar-site/pull/132
>>> [1] https://pulsar.apache.org/community#section-community
>>> [3] https://cassandra.apache.org/_/community.html#meet-the-community
>>> [4] https://flink.apache.org/community.html#people
>>> [5]
>>>
>>> https://github.com/apache/pulsar-site/blob/7441570e2a79c56f073bdc8c3dabe41fbad7411a/site2/website-next/data/team.js#L29
>>> [6] https://spark.apache.org/committers.html
>>>
>>> Yu and Wenqing
>>>
>>

[ANNOUNCE] New Committer: Zixuan Liu

[Yu]

Hi team,

The Project Management Committee (PMC) for Apache Pulsar has invited
Zixuan Liu (https://github.com/nodece) to become a committer
and we are pleased to announce that he has accepted.

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.

Welcome and congratulations, Zixuan Liu!

Please join us in congratulating and welcoming Zixuan Liu onboard!

Best Regards,
Yu on behalf of the Pulsar PMC

Re: Pull requests potentially blocked by the Documentation Bot workflow

[Yu]

Hi team,
Sorry for the inconvenience. We're optimizing the Doc Bot, it does not
function well sometimes.
A quick workaround is to re-trigger the Doc Bot (eg. untick the doc label
check box and tick it again in the PR description), then it will work
normally.

Hi Nicolo,
Please do not push your change since we've already submitted a fix [1].
> If we don't find a quick solution, I'll push a revert to unblock the
master branch.

Feel free to comment, thank you!

[1] https://github.com/apache/pulsar/pull/16437

Yu and Max

On Thu, Jul 7, 2022 at 12:06 PM Michael Marshall 
wrote:

> > You can add a doc-label-missing and then remove it to run the label test.
>
> Thank you for this tip. That helped me move [0] forward.
>
> Doc bot failures are more serious now because the doc bot is now a required
> status check for a PR to be merged.
>
> Thanks,
> Michael
>
> [0] https://github.com/apache/pulsar/pull/16222
>
>
> On Wed, Jul 6, 2022 at 7:03 AM Xiangying Meng 
> wrote:
> >
> > You can add a doc-label-missing and then remove it to run the label test.
> > I have tried this solution several times.
> >
> > On Wed, Jul 6, 2022 at 7:41 PM Nicolò Boschi 
> wrote:
> >
> > > Hi all,
> > >
> > > There are some pull requests blocked by the Doc bot that never ends.
> > > I left a comment here https://github.com/apache/pulsar/pull/16368
> because
> > > I
> > > think this pull is the culprit
> > >
> > > If we don't find a quick solution, I'll push a revert to unblock the
> master
> > > branch
> > >
> > > Thanks,
> > > Nicolò Boschi
> > >
>

New Release Notes Workflow

[Yu]

Hi team (especially release managers),

Since we have a new Pulsar Release Notes page [1], the workflow of
submitting release notes is changed.

I've documented steps and added examples on the wiki [2], please follow the
new rules.

Feel free to comment, thank you!

[1] https://pulsar.apache.org/release-notes/
[2]
https://github.com/apache/pulsar/wiki/Release-process#16-write-release-notes

Yu & urfree