Hey Dongjoon, You're absolutely free to do whatever you please and see fit. When we had the previous discussion on the Go repository, many folks chimed in and indicated that using the issues feature in GitHub lowers the barrier of entry for contributors to the client library. The idea behind this is that new contributors to the client library will be able to identify good starter tasks and report issues faster and more inclusively than requiring them to create an additional account in a second system.
Managing the issues for the client library in Jira is not a blocker, please continue how you see fit. Martin PS: I'm not a fan of the passive-aggressive tone insinuating any negative intent. On Sun, Mar 16, 2025 at 10:18 PM Dongjoon Hyun <dongj...@apache.org> wrote: > Thank you for the suggestion, Martin. > > I prefer to follow `spark` and `spark-kubernetes-operator` repository way > as the traditional Apache Spark way. > > In addition, apparently, it seems that I'm going to maintain > `spark-connect-swift` repository as the main contributor and main reviewer > in most cases. So, please allow me to use my preferred way as the main > worker on that repository. > > Could you tell me how the Apache Spark JIRA is blocking you, Martin? You > are the Apache Spark committer which is supposed to use Apache Spark JIRA > for Spark contribution. I'm interested what kind of difficulty blocks the > Apache Spark committer. > > Thanks, > Dongjoon. > > On 2025/03/16 21:08:08 Martin Grund wrote: > > So I was just playing with the Swift client to build a Mac app and > > everything worked nicely! However, similar to the Go repository, my > > suggestion would be to handle issues directly in Github and not in Jira > > because the vast majority of initial issues will be simply compatibility > > issues. And creating them in Jira instead of GH where I'm already, is > going > > to be a big overhead. > > > > What do you think? > > > > In the Go client, we follow the approach that cross-language issues go to > > Jira, whereas client-specific ones go directly into Github. > > > > On Tue, Mar 11, 2025 at 3:28 AM Jules Damji <jules.da...@gmail.com> > wrote: > > > > > + 1 (non-binding) > > > > > > Generally speaking, it’s a good idea to separate repositories for all > > > Spark Connect clients under Spark. > > > - better organization > > > - better visibility > > > - easier for contribution > > > - better for growth & extension of Spark Connect ecosystem > > > > > > Cheers > > > Jules > > > — > > > Sent from my iPhone > > > Pardon the dumb thumb typos :) > > > > > > > > > — > > > Sent from my iPhone > > > Pardon the dumb thumb typos :) > > > > On Mar 10, 2025, at 4:37 PM, Dongjoon Hyun <dongj...@apache.org> > wrote: > > > > > > > > Thank you everyone for your support. > > > > > > > > New Apache Spark repository is created at the proposed location with > ASF > > > license and open for `Spark Connect Client for Swift language` > > > contributions. > > > > > > > > https://github.com/apache/spark-connect-swift > > > > > > > > FYI, this repository will be managed in the same way with > > > `spark-kubernetes-operator` repository. > > > > > > > > Thank you again. > > > > > > > > Dongjoon. > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org > > > > > > --------------------------------------------------------------------- > > > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org > >
