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