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 >
