Re: Request to contribute to Apache Pulsar JIRA maintenance and documentation
Hi Yuvaraj, Thanks for your willingness to contribute to Pulsar. To answer your question about the client docs in short - No, you don't need to replicate. They are not excluded but restructured in 3.0 according to PIP-228 [1]. This restructuring aims to improve the developer experience by helping them get started with bite-sized info [2] and build a solid model to make the doc set easier to scale. Feel free to continuously improve the docs! [1]: https://github.com/apache/pulsar/issues/18822https://github.com/apache/pulsar/issues/18822 [2]: https://pulsar.apache.org/docs/3.0.x/client-libraries-java/ Best, Jun From: Yuvaraj Madeshwaran Sent: Tuesday, July 11, 2023 3:34 To: Dave Fisher ; li...@apache.org Cc: dev@pulsar.apache.org Subject: Re: Request to contribute to Apache Pulsar JIRA maintenance and documentation Hi Liuyu & Dave, Thanks for sharing the information. I have gone through the documentation of Apache Pulsar and found that the Version 3.0.X documentation for Java client is not complete in the link, https://pulsar.apache.org/docs/3.0.x/client-libraries-java-use/ It's missing documentation for a couple of topics as below, 1. TableView 2. Schema 3. Authentication 4. Cluster Level failover Documentation for the same exists in version below in the link https://pulsar.apache.org/docs/2.11.x/client-libraries-java/ Can you please suggest to me, Do we need to replicate the documentation in Version 3 ? If yes, Shall I fork a new branch, make changes in it ? Thanks in advance! Regards, Yuvaraj Madheswaran
Re: [DISCUSS] We must change the way we review PIPs
+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 > > the > > > > last 6 months, even though I'm just an occasional user. Why? They were > > > > conducted on GitHub PR , so it was easy for me - click a link and > > reply. > > > > > > > > 4. All over the place > > > > Sometimes people comment on the GitHub issue. > > > > Sometimes on the mailing list. > > > > Not a single place. > > > > > > > > 5. No history. > > > > Ok, finally the author was convinced. I can't see just the changes. > > They > > > > need to explicitly tell me something was changed. > > > > > > > > 6. Delete All. > > > > They can go crazy, after 1 year, edit the GitHub issue , delete all the > > > > text and write "Kafka is the king". No history, nobody can stop them. > > > It's > > > > their issue. > > > > > > > > 7. Show me all the approved PIPs > > > > Hard to track it today,
Re: [ANNOUNCE] Qiang Zhao as new PMC member in Apache Pulsar
Congrats, Qiang! Cheers, Jun
Implement canonical URLs in Pulsar docs for SEO
Hi, everyone, When researching tagging metadata to Pulsar docs for SEO, I found this issue that we don't have a strategy/implementation to always return the latest stable version of Pulsar docs in the Google search results [1], leading to confusion and bad UX. After searching existing issues, I found the same issue was previously reported by @visortelle last year, and he also provided some insights and references in this comment [2]. I think this is the biggest gap we need to fix regarding SEO. So I'm writing this email to ask - if any SEO experts in our community know about how to implement canonical URLs globally within the Docusaurus framework or any other alternatives? It would be much more efficient and maintainable than configuring each markdown file. I'm looking forward to hearing your thoughts and ideas. [1]: https://github.com/apache/pulsar/issues/18190#issuecomment-1469269560 [2]: https://github.com/apache/pulsar/issues/18190#issuecomment-1295281487 Cheers, Jun
[Discuss] Review the new structure of client library documentation
Hi everyone, To improve the developer experience and onboard Pulsar users more efficiently, I proposed PIP-228 to refactor the client library documentation [1] and got three binding votes [2]. @RobertIndie and I have been working on implementing the information architecture changes through this pull request [3] by mapping the existing docs to users’ learning paths. Note that this PR only focuses on the structure improvements, while the detailed content itself definitely needs to be reviewed and enriched through a series of pull requests later. We don’t want to throw any surprises without staging it, so this is a call to invite more eyes to preview the new structure and make sure everyone who cares about these topics is informed of this upcoming change. Check out the new structure and add your comments:) [1]: https://github.com/apache/pulsar/issues/18822 [2]: https://lists.apache.org/thread/5g0mhvks90nx4sh7fnpmkqj6k2dvxjpp [3]: https://github.com/apache/pulsar-site/pull/393 Best, Jun
Re: [ANNOUNCE] Nicolò Boschi as new PMC member in Apache Pulsar
Congratulations, Nicolò! From: Lari Hotari Sent: Friday, January 20, 2023 20:36 To: dev@pulsar.apache.org Subject: [ANNOUNCE] Nicolò Boschi as new PMC member in Apache Pulsar 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: [ANNOUNCE] Bo Cong as new PMC member in Apache Pulsar
Congratulations, Bo! From: PengHui Li Sent: Wednesday, January 18, 2023 21:50 To: Dev Subject: [ANNOUNCE] Bo Cong as new PMC member in Apache Pulsar Hi all, The Apache Pulsar Project Management Committee (PMC) has invited Bo Cong (https://github.com/congbobo184) 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 such as transactions and schemas. Welcome Bo Cong to the Apache Pulsar PMC. Best Regards, Penghui on behalf of the Pulsar PMC
Re: [ANNOUNCE] New Committer: Baodi Shi
Congratulations, Baodi! From: Yunze Xu Sent: Wednesday, January 18, 2023 21:35 To: dev@pulsar.apache.org Subject: [ANNOUNCE] New Committer: Baodi Shi The Project Management Committee (PMC) for Apache Pulsar has invited Baodi Shi (https://github.com/shibd) 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, Baodi Shi! Please join us in congratulating and welcoming Baodi Shi onboard! Thanks, Yunze on behalf of the Pulsar PMC
Re: [PROPOSAL] Website precommit and move the source of docs to the site repo
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, > > 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, > > > > > > > > >
Re: [DISCUSS] PIP-228: Refactor the information architecture of Pulsar client docs
Hi Zike, Thanks for your feedback! This inaccessible link can be removed because the proposed IA has been shown in the following image. Thanks for pointing it out. From: Zike Yang Sent: Wednesday, December 14, 2022 19:51 To: dev@pulsar.apache.org Subject: Re: [DISCUSS] PIP-228: Refactor the information architecture of Pulsar client docs Hi Jun, Thanks for your PIP. Overall looks good to me. > The Client concepts topic does not introduce the basic client concepts and > can be enriched with content relocated from other topics. See Proposed IA for > more details. The link of `Proposed IA` doesn't work. Need to grant the access permission. Thanks, Zike Yang On Thu, Dec 8, 2022 at 8:47 PM Jun Ma wrote: > > Hi, all, > > I've created PIP-228 to discuss - Refactor the Information Architecture of > Pulsar Client Docs. > > > Motivation > > * Improve the developer experience and help them get started by offering > bite-sized basics in the docs. > * Build a solid content structure to make it easier to increment and > scale. > * Contribute to Pulsar adoption. > > For more details, please read the PIP at > https://github.com/apache/pulsar/issues/18822. > I'm looking forward to hearing what you think. > > Best, > Jun
[VOTE] PIP-228: Refactor the information architecture of Pulsar client docs
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
[DISCUSS] PIP-228: Refactor the information architecture of Pulsar client docs
Hi, all, I've created PIP-228 to discuss - Refactor the Information Architecture of Pulsar Client Docs. Motivation * Improve the developer experience and help them get started by offering bite-sized basics in the docs. * Build a solid content structure to make it easier to increment and scale. * Contribute to Pulsar adoption. For more details, please read the PIP at https://github.com/apache/pulsar/issues/18822. I'm looking forward to hearing what you think. Best, Jun
Re: [ANNOUNCE] New Committer: Cong Zhao
Congratulations, Cong @coderzc ! From: PengHui Li Sent: Monday, November 21, 2022 17:13 To: dev@pulsar.apache.org Subject: Re: [ANNOUNCE] New Committer: Cong Zhao Congrats! Cong Thanks, Penghui > On Nov 21, 2022, at 13:57, Zixuan Liu wrote: > > Congrats! Cong > > Best Regards, > Zixuan > > houxiaoyu 于2022年11月21日周一 12:24写道： > >> Congrats! Cong >> >> Best, >> Xiaoyu Hou >> >> Haiting Jiang 于2022年11月21日周一 12:10写道： >> >>> The Project Management Committee (PMC) for Apache Pulsar has invited >>> Cong Zhao (https://github.com/coderzc) >>> 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, Cong Zhao! >>> >>> Please join us in congratulating and welcoming Cong Zhao onboard! >>> >>> Best Regards, >>> Haiting on behalf of the Pulsar PMC >>> >>
Re: [ANNOUNCE] New Committer: Zili Chen
Congratulations! > > 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: [ANNOUNCE] Haiting Jiang as a new PMC member in Apache Pulsar
Congratulations, Haiting! Best, Jun From: Yunze Xu Sent: Wednesday, October 19, 2022 23:23 To: dev@pulsar.apache.org Subject: Re: [ANNOUNCE] Haiting Jiang as a new PMC member in Apache Pulsar Congrats! Thanks, Yunze On Tue, Oct 18, 2022 at 4:06 PM Hang Chen wrote: > > Hi all, > > The Apache Pulsar Project Management Committee (PMC) has invited Haiting Jiang > (https://github.com/Jason918) as a member of the PMC and we are > pleased to announce that he has accepted. > > He is very active in the community on GitHub. > > Welcome Haiting to the Apache Pulsar PMC > > Best Regards, > Hang Chen on behalf of the Pulsar PMC
Re: [ANNOUNCE] New Committer: Qiang Huang
Congratulations, Qiang! From: Xiangying Meng Sent: Friday, October 14, 2022 14:17 To: dev@pulsar.apache.org Subject: Re: [ANNOUNCE] New Committer: Qiang Huang Congratulations Qiang Huang Thanks, Xiangying On Fri, Oct 14, 2022 at 2:04 PM Haiting Jiang wrote: > Congratulations! > > Best, > Haiting > > On Fri, Oct 14, 2022 at 1:58 PM Max Xu wrote: > > > > Congratulations! Qiang > > > > Best, > > Max Xu > > > > > > On Fri, Oct 14, 2022 at 12:04 PM guo jiwei wrote: > > > > > The Project Management Committee (PMC) for Apache Pulsar has invited > > > Qiang Huang (https://github.com/hqebupt) to become a committer and > > > we are pleased to announce that he has accepted. > > > > > > Qiang Huang (with Github id: hqebupt) contributed many improvements > > > and bug fixes to Pulsar. > > > > > > 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, Qiang Huang! > > > > > > Please join us in congratulating and welcoming Qiang Huang onboard! > > > > > > > > > Regards > > > Jiwei Guo on behalf of the Pulsar PMC > > > >
[DISCUSS] Create a robust and inline Client Feature Matrix page
Hi, Pulsar community, As you may notice, the Client Feature Matrix [0] has been linked on the Pulsar doc site [1] for quite a while, providing an overview of feature supportability on language-specific clients. As the outcome of PIP-108, it has addressed the initial community request [2] for technology evaluation and selection. However, it has the following limitations to continually serving the purpose over time: 1. Visibility: Not prominent for users/maintainers to notice it. 2. Process: No required review/approval or version control. 3. Accuracy: A bit out-of-dated with limited chances to get it updated (possibly caused by 1&2). To make it more robust and prominent to better serve the adoption purpose, I think we can make the following improvements: 1. Deliver a more robust Client Feature Matrix and required documentation through a thorough review and update. 2. Move the matrix to the Pulsar repo and display it inline on a web page. Refer to this reference [3]. A quick question is about the granularity of the feature sets presented in the new matrix. Generally, we have two options: 1. Display a full version as we do in the existing feature matrix to provide more detailed tech capabilities. 2. Display a compact version with high-level features to provide better readability. Feel free to share your thoughts. [0] https://docs.google.com/spreadsheets/d/1YHYTkIXR8-Ql103u-IMI18TXLlGStK8uJjDsOOA0T20/edit?usp=sharing [1] https://pulsar.apache.org/docs/next/client-libraries#feature-matrix [2] https://github.com/apache/pulsar/issues/9723 [3] https://beam.apache.org/documentation/runners/capability-matrix/when-in-processing-time/ Cheers, momo-jun
