> This google sheet [1] has been already contributed to our community. > Everyone has access to view and comment on it.
Thank you for clarifying. This google sheet is filled with very valuable, detailed information! My thought is that putting the information into a table on the website, and not just on a Google Sheet referenced by the website, would simplify access because users would not need to leave the Pulsar website to view it. It would also let search engines index the pages, and then the pages could show up search results. > We're updating the sheet all the time. If we're still updating the Sheet frequently, I can see that it might be cumbersome to keep up to date using GitHub. On the other hand, by putting it in our git repo, it would be easier for anyone to contribute changes without giving blanket write access to the doc. Git would also provide a public record of the history of the doc. > Fixed, PTAL [2] Thanks for fixing it. Thanks, Michael On Thu, Jan 27, 2022 at 1:55 AM Yu <li...@apache.org> wrote: > > Hi Michael, > > Thanks for raising this up. > > > It is only in a Google Sheet right now, though. Maybe the owners of > the Google doc would consider contributing it to the website? > > This google sheet [1] has been already contributed to our community. > Everyone has access to view and comment on it. > > > The website references this matrix on this page [1], but the link is > broken. > > Fixed, PTAL [2] > > > Additionally, we could adopt the practice of sending a note to the > mailing list when we add new features or find tricky bugs for any of > our clients. > > +1 > We're updating the sheet all the time. > For example, if we have new features, we add both code and doc status. > Recently, we've added ack cumulative (Node.js), chunking > (Java), cluster-level auto failover (Java), and more. > Feel free to comment, thanks. > > [1] > https://docs.google.com/spreadsheets/d/1YHYTkIXR8-Ql103u-IMI18TXLlGStK8uJjDsOOA0T20/edit#gid=1784579914 > [2] https://github.com/apache/pulsar/pull/13977 > > On Thu, Jan 27, 2022 at 1:00 AM Michael Marshall <mmarsh...@apache.org> > wrote: > > > We have a Client Features Matrix page on the GitHub wiki [0]. This > > seems like a helpful and relevant resource for this thread. > > > > It is only in a Google Sheet right now, though. Maybe the owners of > > the Google doc would consider contributing it to the website? > > > > The website references this matrix on this page [1], but the link is > > broken. > > > > Additionally, we could adopt the practice of sending a note to the > > mailing list when we add new features or find tricky bugs for any of > > our clients. > > > > Thanks, > > Michael > > > > [0] > > https://github.com/apache/pulsar/wiki/PIP-108:-Pulsar-Feature-Matrix-(Client-and-Function) > > [1] https://pulsar.apache.org/docs/en/client-libraries/ > > > > On Thu, Jan 13, 2022 at 8:53 PM r...@apache.org <ranxiaolong...@gmail.com> > > wrote: > > > > > > Good ideas, we need such a mechanism to complement the current process to > > > ensure that other language SDKs know what's going on with the Java SDK, > > > which would be a good start for other language SDKs. We can clearly see > > > where the gap between the current SDK and the Java SDK is, which new > > > functions we need to support, and which bugs we need to modify. > > > > > > We can perform this process manually first, although it is troublesome, > > but > > > in this action, we can find out what we need to do to automate such a > > > process, I believe this will be a good start. > > > > > > -- > > > Thanks > > > Xiaolong Ran > > > > > > PengHui Li <peng...@apache.org> 于2022年1月13日周四 11:16写道： > > > > > > > I'm not sure if the bots can detect if the change is a Java client > > change, > > > > maybe based on the changes introduced in which directory. > > > > > > > > The main headache here is missing it. If there are some mechanisms > > that can > > > > remind us. > > > > It will be great. Looks like > > > > > > > > "hey, new changes introduced in Java client, you might need to create > > an > > > > issue to other clients repos" > > > > > > > > Use a label to allow the bots to sync to other repos LGTM here, we can > > run > > > > it manually first. > > > > So that we can know more clearly if we need automatic synchronization. > > > > > > > > Thanks, > > > > Penghui > > > > > > > > On Wed, Jan 12, 2022 at 9:06 PM Zike Yang <zky...@streamnative.io > > .invalid> > > > > wrote: > > > > > > > > > +1 > > > > > > > > > > > I wonder if we can create issue in client repo automatically with > > bots > > > > > for PRs labelled"component/client" in pulsar repo. > > > > > > This would save the extra effort for the reviewer. > > > > > > > > > > But there are many PRs with "component/client" label that are > > specific > > > > > to java client changes. I think these should not be added to other > > > > > clients' repos. > > > > > > > > > > > > > > > > > > > > On Wed, Jan 12, 2022 at 4:18 PM Haiting Jiang < > > jianghait...@apache.org> > > > > > wrote: > > > > > > > > > > > > +1. Great idea. > > > > > > > > > > > > I wonder if we can create issue in client repo automatically with > > bots > > > > > for PRs labelled"component/client" in pulsar repo. > > > > > > This would save the extra effort for the reviewer. > > > > > > > > > > > > Thanks, > > > > > > Haiting Jiang > > > > > > > > > > > > On 2022/01/12 03:45:18 "r...@apache.org" wrote: > > > > > > > Hello everyone: > > > > > > > > > > > > > > At present, all our PIP and related function changes are mainly > > in > > > > the > > > > > Java > > > > > > > language, and all new functions will be merged into the Java SDK > > > > > first, but > > > > > > > for SDKs in other languages, this is completely a black box, they > > > > don't > > > > > > > know what changes or optimizations have been made on the Java SDK > > > > side. > > > > > > > > > > > > > > The most typical problem is that when users of other languages > > > > > encounter > > > > > > > various problems during use, when the maintainers of other > > languages > > > > > want > > > > > > > to fix these problems, we do not know that the Java SDK side has > > made > > > > > these > > > > > > > changes. Therefore, every current solution is to constantly check > > > > > where the > > > > > > > gap of the current Java SDK is, which brings great challenges to > > the > > > > > > > maintainers themselves. > > > > > > > > > > > > > > So here is an idea, when the committters/PMC responsible for > > > > reviewing > > > > > the > > > > > > > Java SDK can do more to help evaluate whether these PIPs or new > > > > changes > > > > > > > need to support this function in other languages, and then the > > > > > > > corresponding issue is created in the corresponding SDK, so that > > it > > > > is > > > > > > > convenient for the maintainers of other language SDKs to further > > > > > evaluate > > > > > > > the priority of this function, and it can also attract more > > > > > contributors > > > > > > > who are good at certain languages to claim the corresponding > > issue > > > > and > > > > > > > contribute the corresponding function. > > > > > > > > > > > > > > -- > > > > > > > Thanks > > > > > > > Xiaolong Ran > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Zike Yang > > > > > > > > > > >
