Re: [Discuss] Create new issues to SDKs in different languages

[Michael Marshall <mm...@apache.org>]

> 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 <mm...@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 rxl@apache.org <ra...@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 <pe...@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 <zkyang@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 <
> > jianghaiting@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 "rxl@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
> > > > >
> > > >
> >

Re: [Discuss] Create new issues to SDKs in different languages

[Yu <li...@apache.org>]

Hi Michael,

Thanks for your suggestion! We're just back from the Lunar New Year holiday.

> My thought is that putting the information into a table on the website,
and not just on a Google Sheet referenced by the website

Each way has its advantages and limitations, I still prefer to keep the
info in the Google Sheet because:
1) if anyone wants to update the info, since they are pretty
*complicated* tables, it is much more convenient to update the info in
Google Sheet rather than in markdown tables
2) if anyone wants to make comments, it is convenient to leave them in
Google Sheet rather than discussing them anywhere else.

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

Currently, I'm the only one who update the Matrix frequently. If anyone
would like to contribute together, I can grant access to you. Welcome to
join us.


On Tue, Feb 1, 2022 at 12:22 PM Michael Marshall <mm...@apache.org>
wrote:

> > 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 <mm...@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 rxl@apache.org <
> ranxiaolong716@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 <pe...@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 <zkyang@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 <
> > > jianghaiting@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 "rxl@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
> > > > > >
> > > > >
> > >
>