Mich, yes, the goal is to make it easier for folks to contribute to the Go client, and my discussion is related to the https://github.com/apache/spark-connect-go repository only and thanks a lot for the feedback. My assumption is that we will monitor the GH issues in the same way as we do for the Jira issues (e.g. they can go to the same mailing list etc) The feedback that you provided is really helpful as it outlines what we have to do for release management of the Go client as well.
Sean, according to https://infra.apache.org/services.html#issue-tracking projects can use JIRA and GH issues, see as well here for the self-serve instructions - https://infra.apache.org/request-bug-tracker.html Please keep the feedback coming. On Thu, Aug 8, 2024 at 2:43 PM Sean Owen <sro...@gmail.com> wrote: > This is still part of the Apache Spark project, conceptually? > IIRC Apache projects still need to use JIRA, so we can't do this. > > On Thu, Aug 8, 2024 at 5:08 AM Mich Talebzadeh <mich.talebza...@gmail.com> > wrote: > >> Hi Martin, >> >> If I understood it correctly, your proposal suggests centralizing issue >> tracking for the Spark Connect Go client on GitHub Issues, instead of using >> both Jira and GitHub.? The primary motivation is to simplify the >> contribution process for developers? >> >> Few points if I may: >> >> >> - How will critical or high-priority issues be handled within GitHub >> Issues? >> - What mechanisms will be in place to ensure timely response and >> resolution of issues? >> - How will the participants measure and track issue resolution and >> development progress? >> - What is the plan for migrating existing Jira issues to GitHub >> Issues? >> >> >> HTH, >> >> Mich Talebzadeh, >> Architect | Data Engineer | Data Science | Financial Crime >> >> PhD <https://en.wikipedia.org/wiki/Doctor_of_Philosophy> Imperial >> College London <https://en.wikipedia.org/wiki/Imperial_College_London> >> London, United Kingdom >> >> *Disclaimer:* The information provided is correct to the best of my >> knowledge but of course cannot be guaranteed . It is essential to note >> that, as with any advice, quote "one test result is worth one-thousand >> expert opinions (Werner >> <https://en.wikipedia.org/wiki/Wernher_von_Braun>Von Braun >> <https://en.wikipedia.org/wiki/Wernher_von_Braun>)". >> >> >> On Thu, 8 Aug 2024 at 06:54, Martin Grund <mar...@databricks.com.invalid> >> wrote: >> >>> Hi folks, >>> >>> I wanted to start a discussion for the following proposal: To make it >>> easier for folks to contribute to the Spark Connect Go client, I was >>> contemplating not requiring them to deal with two accounts (one for Jira) >>> and one for Gihutb but allow using GitHub Issues for bugs and issues that >>> are specific to *only* the Spark Connect Go client. >>> >>> Jira will still be used for issues that span core Spark. This allows us >>> to easily label issues for starter tasks in one place, for example. >>> >>> I am explicitly not proposing to change the behavior for the main Spark >>> repository; here, the existing procedure remains. >>> >>> What do you think? >>> >>> Martin >>> >>
