+1

On Sat, Jul 6, 2024 at 4:45 AM bo yang <bobyan...@gmail.com> wrote:

> +1 This is a great suggestion, thanks Hyukjin!
>
>
> On Thu, Jul 4, 2024 at 4:11 AM Hyukjin Kwon <gurwls...@apache.org> wrote:
>
>> Alright! let me start the vote!
>>
>> On Thu, 4 Jul 2024 at 16:31, Mich Talebzadeh <mich.talebza...@gmail.com>
>> wrote:
>>
>>> A good point agreed.
>>>
>>> Mich Talebzadeh,
>>> Technologist | Architect | Data Engineer  | Generative AI | FinCrime
>>> PhD <https://en.wikipedia.org/wiki/Doctor_of_Philosophy> Imperial
>>> College London <https://en.wikipedia.org/wiki/Imperial_College_London>
>>> London, United Kingdom
>>>
>>>
>>>    view my Linkedin profile
>>> <https://www.linkedin.com/in/mich-talebzadeh-ph-d-5205b2/>
>>>
>>>
>>>  https://en.everybodywiki.com/Mich_Talebzadeh
>>>
>>>
>>>
>>> *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, 4 Jul 2024 at 06:14, Martin Grund <mar...@databricks.com.invalid>
>>> wrote:
>>>
>>>> Absolutely we should do that. I thought that the default rule was
>>>> inclusive already so that once folks have their first contribution it would
>>>> automatically allow kicking of the workflows.
>>>>
>>>> On Thu, Jul 4, 2024 at 04:20 Matthew Powers <
>>>> matthewkevinpow...@gmail.com> wrote:
>>>>
>>>>> Yea, this would be great.
>>>>>
>>>>> spark-connect-go is still experimental and anything we can do to get
>>>>> it production grade would be a great step IMO.  The Go community is 
>>>>> excited
>>>>> to write Spark... with Go!
>>>>>
>>>>> On Wed, Jul 3, 2024 at 8:49 PM Hyukjin Kwon <gurwls...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> The Spark Connect Go client repository (
>>>>>> https://github.com/apache/spark-connect-go) requires GitHub Actions
>>>>>> runs for individual commits within contributors' PRs.
>>>>>>
>>>>>> This policy was intentionally applied (
>>>>>> https://issues.apache.org/jira/browse/INFRA-24387), but we can
>>>>>> change this default once we reach a consensus on it.
>>>>>>
>>>>>> I would like to allow GitHub Actions runs for contributors by default
>>>>>> to make the development faster. For now, I have been approving individual
>>>>>> commits in their PRs, and this becomes overhead.
>>>>>>
>>>>>> If you have any feedback on this, please let me know.
>>>>>>
>>>>>

Reply via email to