rastructure.
>
>
> On Sat, Aug 10, 2024 at 6:30 AM yangjie01
> wrote:
>
>> +1
>>
>>
>>
>> *发件人**: *Jungtaek Lim
>> *日期**: *2024年8月10日 星期六 07:12
>> *收件人**: *Denny Lee
>> *抄送**: *bo yang , Kent Yao , "
>> dev@spark.apache.
[外部邮件] Re: [DISCUSS] Using Github Issues for Spark-Connect-Go
> _only_ issues.
>
>
>
> +1, good size project for experiments and it’s not a one way door
>
>
>
> 2024년 8월 10일 (토) 오전 1:09, Denny Lee 님이 작성:
>
> +1 (non-binding) to start as a small experiment
>
>
+1
发件人: Jungtaek Lim
日期: 2024年8月10日 星期六 07:12
收件人: Denny Lee
抄送: bo yang , Kent Yao ,
"dev@spark.apache.org"
主题: [外部邮件] Re: [DISCUSS] Using Github Issues for Spark-Connect-Go _only_ issues.
+1, good size project for experiments and it’s not a one way door
2024년 8월 10일 (토) 오전 1:09,
+1, good size project for experiments and it’s not a one way door
2024년 8월 10일 (토) 오전 1:09, Denny Lee 님이 작성:
> +1 (non-binding) to start as a small experiment
>
> On Fri, Aug 9, 2024 at 11:56 PM bo yang wrote:
>
>> +1 to start small as an experiment to see how people use GitHub issue...
>>
>> On
..+1 to start small as an experiment to see how people use GitHub issues...
That may be an approach, My suggestion is an industry standard Proof of
Concept (PoC) which is an accepted approach for testing the feasibility of
using GitHub Issues for managing Spark Connect Go client issues. This is a
+1 (non-binding) to start as a small experiment
On Fri, Aug 9, 2024 at 11:56 PM bo yang wrote:
> +1 to start small as an experiment to see how people use GitHub issue...
>
> On Thu, Aug 8, 2024 at 11:54 PM Kent Yao wrote:
>
>> +1
>>
>> On 2024/08/08 23:24:32 Hyukjin Kwon wrote:
>> > SGTM
>> >
>
+1 to start small as an experiment to see how people use GitHub issue...
On Thu, Aug 8, 2024 at 11:54 PM Kent Yao wrote:
> +1
>
> On 2024/08/08 23:24:32 Hyukjin Kwon wrote:
> > SGTM
> >
> > On Thu, 8 Aug 2024 at 14:53, Martin Grund >
> > wrote:
> >
> > > Hi folks,
> > >
> > > I wanted to start
+1
On 2024/08/08 23:24:32 Hyukjin Kwon wrote:
> SGTM
>
> On Thu, 8 Aug 2024 at 14:53, Martin Grund
> 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 no
SGTM
On Thu, 8 Aug 2024 at 14:53, Martin Grund
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
Hi Martin,
Overall, your proposal seems to align well with improving the contributor
experience and managing issues more effectively for the Spark Connect Go
client. As long as there is a plan to handle potential integration
challenges and clear communication with the community, this approach coul
I'd love that too. But maybe we can start small and try it out with one
project ...
On Thu, Aug 8, 2024 at 7:16 AM Sean Owen wrote:
> Oh nice if that has changed. Id personally prefer switching all of Spark
> to GitHub issues for simplicity but maybe that's a big lift. And a separate
> question.
Oh nice if that has changed. Id personally prefer switching all of Spark to
GitHub issues for simplicity but maybe that's a big lift. And a separate
question.
On Thu, Aug 8, 2024, 9:12 AM Martin Grund wrote:
> Mich, yes, the goal is to make it easier for folks to contribute to the Go
> client, a
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 J
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
wrote:
> Hi Martin,
>
> If I understood it correctly, your proposal suggests centralizing issue
> tracking for the Spark
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 wil
15 matches
Mail list logo
