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