Re: [VOTE] Apache Spark PMC asks Databricks to differentiate its Spark version string

[Dongjoon Hyun]

Here are my replies, Sean.

> Since we're here, fine: I vote -1, simply because this states no reason
for the action at all.

Thank you for your explicit vote because
this vote was explicitly triggered by this controversial comment,
"I do not see some police action from the PMC must follow".


> I would again ask we not simply repeat the same thread again.

We are in the next stage from the previous discussion which identified
our diverse perspective. The vote is the only official way to make a
conclusion, isn't it?


> - Relevant ASF policy seems to say this is fine,
> as argued at
https://lists.apache.org/thread/p15tc772j9qwyvn852sh8ksmzrol9cof

I already disagreed with the above point, "this is fine", at
https://lists.apache.org/thread/crp01jg4wr27w10mc9dsbsogxm1qj6co .


> - There is no argument any of this has caused a problem
> for the community anyway

Shall we focus on legal scope on this vote because we are
talking about ASF branding policy? For the record, the above perspective
implies
Apache Spark PMC should ignore ASF branding policy.


> Given that this has stopped being about ASF policy, ...

I want to emphasize that this statement vote is only about
Apache Spark PMC's stance ("Ask or not Ask").
If the vote decides not to ask, that's it.


Dongjoon.


On Fri, Jun 16, 2023 at 2:23 PM Sean Owen  wrote:

> On Fri, Jun 16, 2023 at 3:58 PM Dongjoon Hyun 
> wrote:
>
>> I started the thread about already publicly visible version issues
>> according to the ASF PMC communication guideline. It's no confidential,
>> personal, or security-related stuff. Are you insisting this is confidential?
>>
>
> Discussion about a particular company should be on private@ - this is
> IMHO like "personnel matters", in the doc you link. The principle is that
> discussing whether an entity is doing something right or wrong is better in
> private, because, hey, if the conclusion is "nothing's wrong here" then you
> avoid disseminating any implication to the contrary.
>
> I agreed with you, there's some value in discussing the general issue on
> dev@. (I even said who the company was, though, it was I think clear
> before)
>
> But, your thread title here is: "Apache Spark PMC asks Databricks to
> differentiate its Spark version string"
> (You separately claim this vote is about whether the PMC has a role here,
> but, that's plainly not how this thread begins.)
>
> Given that this has stopped being about ASF policy, and seems to be about
> taking some action related to a company, I find it inappropriate again for
> dev@, for exactly the reason I gave above. We have a PMC member repeating
> this claim over and over, without support. This is why we don't do this in
> public.
>
>
>
>> May I ask which relevant context you are insisting not to receive
>> specifically? I gave the specific examples (UI/logs/screenshot), and got
>> the specific legal advice from `legal-discuss@` and replied why the
>> version should be different.
>>
>
> It is the thread I linked in my reply:
> https://lists.apache.org/thread/k7gr65wt0fwtldc7hp7bd0vkg1k93rrb
> This has already been discussed at length, and you're aware of it, but,
> didn't mention it. I think that's critical; your text contains no problem
> statement at all by itself.
>
> Since we're here, fine: I vote -1, simply because this states no reason
> for the action at all.
> If we assume the thread ^^^ above is the extent of the logic, then, -1 for
> the following reasons:
> - Relevant ASF policy seems to say this is fine, as argued at
> https://lists.apache.org/thread/p15tc772j9qwyvn852sh8ksmzrol9cof
> - There is no argument any of this has caused a problem for the community
> anyway; there is just nothing to 'fix'
>
> I would again ask we not simply repeat the same thread again.
>
>

Re: [VOTE] Apache Spark PMC asks Databricks to differentiate its Spark version string

[Mich Talebzadeh]

Since the genie is out of the bottle now and I have been involved in this
discussion all the way, I think the question ought to be  "Apache Spark DEV
community asks Databricks to differentiate its Spark version string". That
makes more sense as Spark DEV community is a superset of PMC if I am not
wrong". Whether Spark DEV community can make such request is another matter,

That aside, I believe both Dongioon and Sean passionately believe in their
respective views  so this is going to be a hard nut to crack.  A good
number of Spark DEV community members work for Databricks as well so there
is a potential conflict of interest here.  Notwithstanding there are
multiple other companies that use Spark version in one form or shape, so
how about them! Even if we collect 100 votes, what Apache Spark is going to
do if Databricks or for that matter others ignore the request and the
request backfires.

Franfly, I don't think it is worth the effort, regardless of how
passionately we believe in it. I vote to let it rest.

HTH

Mich Talebzadeh,
Lead Solutions Architect/Engineering Lead
Palantir Technologies Limited
London
United Kingdom


   view my Linkedin profile



 https://en.everybodywiki.com/Mich_Talebzadeh



*Disclaimer:* Use it at your own risk. Any and all responsibility for any
loss, damage or destruction of data or any other property which may arise
from relying on this email's technical content is explicitly disclaimed.
The author will in no case be liable for any monetary damages arising from
such loss, damage or destruction.




On Fri, 16 Jun 2023 at 21:23, Sean Owen  wrote:

> As we noted in the last thread, this discussion should have been on
> private@ to begin with, but, the ship has sailed.
>
> You are suggesting that non-PMC members vote on whether the PMC has to do
> something? No, that's not how anything works here.
> It's certainly the PMC that decides what to put in the board report, or
> take action on behalf of the project.
>
> This doesn't make sense here. Frankly, repeating this publicly without
> relevant context, and avoiding the response you already got, is
> inappropriate.
>
> You may call a PMC vote on whether there's even an issue here, sure. If
> you pursue it, you should explain specifically what the issue is w.r.t.
> policy, and argue against the response you've already received.
> We put valid issues in the board report, for sure. We do not include
> invalid issues in the board report. That part needs no decision from anyone.
>
>
> On Fri, Jun 16, 2023 at 3:08 PM Dongjoon Hyun 
> wrote:
>
>> No, this is a vote on dev@ intentionally as a part of our previous
>> thread, "ASF policy violation and Scala version issues" (
>> https://lists.apache.org/thread/k7gr65wt0fwtldc7hp7bd0vkg1k93rrb)
>>
>> > did you mean this for the PMC list?
>>
>> I clearly started the thread with the following.
>> > - Apache Spark PMC should include this incident report and the result
>> in the next Apache Spark Quarterly Report (August).
>>
>> However, there is a perspective that this is none of Apache Spark PMC's
>> role here.
>>
>> That's the rationale of this vote.
>>
>> This vote is whether this is Apache Spark PMC's role or not.
>>
>> Dongjoon.
>>
>

Re: [VOTE] Apache Spark PMC asks Databricks to differentiate its Spark version string

[Sean Owen]

On Fri, Jun 16, 2023 at 3:58 PM Dongjoon Hyun 
wrote:

> I started the thread about already publicly visible version issues
> according to the ASF PMC communication guideline. It's no confidential,
> personal, or security-related stuff. Are you insisting this is confidential?
>

Discussion about a particular company should be on private@ - this is IMHO
like "personnel matters", in the doc you link. The principle is that
discussing whether an entity is doing something right or wrong is better in
private, because, hey, if the conclusion is "nothing's wrong here" then you
avoid disseminating any implication to the contrary.

I agreed with you, there's some value in discussing the general issue on
dev@. (I even said who the company was, though, it was I think clear before)

But, your thread title here is: "Apache Spark PMC asks Databricks to
differentiate its Spark version string"
(You separately claim this vote is about whether the PMC has a role here,
but, that's plainly not how this thread begins.)

Given that this has stopped being about ASF policy, and seems to be about
taking some action related to a company, I find it inappropriate again for
dev@, for exactly the reason I gave above. We have a PMC member repeating
this claim over and over, without support. This is why we don't do this in
public.



> May I ask which relevant context you are insisting not to receive
> specifically? I gave the specific examples (UI/logs/screenshot), and got
> the specific legal advice from `legal-discuss@` and replied why the
> version should be different.
>

It is the thread I linked in my reply:
https://lists.apache.org/thread/k7gr65wt0fwtldc7hp7bd0vkg1k93rrb
This has already been discussed at length, and you're aware of it, but,
didn't mention it. I think that's critical; your text contains no problem
statement at all by itself.

Since we're here, fine: I vote -1, simply because this states no reason for
the action at all.
If we assume the thread ^^^ above is the extent of the logic, then, -1 for
the following reasons:
- Relevant ASF policy seems to say this is fine, as argued at
https://lists.apache.org/thread/p15tc772j9qwyvn852sh8ksmzrol9cof
- There is no argument any of this has caused a problem for the community
anyway; there is just nothing to 'fix'

I would again ask we not simply repeat the same thread again.

Re: [VOTE] Apache Spark PMC asks Databricks to differentiate its Spark version string

[Dongjoon Hyun]

For the following,

> this discussion should have been on private@ to begin with, but, the ship
has sailed. ...
> This doesn't make sense here.

I started the thread about already publicly visible version issues
according to the ASF PMC communication guideline. It's no confidential,
personal, or security-related stuff. Are you insisting this is confidential?

- https://www.apache.org/foundation/governance/pmcs#communication
> Virtually all PMC communication should happen
> on the dev@ list or any other appropriate public mailing list.


May I ask which relevant context you are insisting not to receive
specifically? I gave the specific examples (UI/logs/screenshot), and got
the specific legal advice from `legal-discuss@` and replied why the version
should be different.

> Frankly, repeating this publicly without relevant context, and avoiding
the response you already got, is inappropriate.


Dongjoon.


On Fri, Jun 16, 2023 at 1:23 PM Sean Owen  wrote:

> As we noted in the last thread, this discussion should have been on
> private@ to begin with, but, the ship has sailed.
>
> You are suggesting that non-PMC members vote on whether the PMC has to do
> something? No, that's not how anything works here.
> It's certainly the PMC that decides what to put in the board report, or
> take action on behalf of the project.
>
> This doesn't make sense here. Frankly, repeating this publicly without
> relevant context, and avoiding the response you already got, is
> inappropriate.
>
> You may call a PMC vote on whether there's even an issue here, sure. If
> you pursue it, you should explain specifically what the issue is w.r.t.
> policy, and argue against the response you've already received.
> We put valid issues in the board report, for sure. We do not include
> invalid issues in the board report. That part needs no decision from anyone.
>
>
> On Fri, Jun 16, 2023 at 3:08 PM Dongjoon Hyun 
> wrote:
>
>> No, this is a vote on dev@ intentionally as a part of our previous
>> thread, "ASF policy violation and Scala version issues" (
>> https://lists.apache.org/thread/k7gr65wt0fwtldc7hp7bd0vkg1k93rrb)
>>
>> > did you mean this for the PMC list?
>>
>> I clearly started the thread with the following.
>> > - Apache Spark PMC should include this incident report and the result
>> in the next Apache Spark Quarterly Report (August).
>>
>> However, there is a perspective that this is none of Apache Spark PMC's
>> role here.
>>
>> That's the rationale of this vote.
>>
>> This vote is whether this is Apache Spark PMC's role or not.
>>
>> Dongjoon.
>>
>

Re: [VOTE] Apache Spark PMC asks Databricks to differentiate its Spark version string

[Sean Owen]

As we noted in the last thread, this discussion should have been on private@
to begin with, but, the ship has sailed.

You are suggesting that non-PMC members vote on whether the PMC has to do
something? No, that's not how anything works here.
It's certainly the PMC that decides what to put in the board report, or
take action on behalf of the project.

This doesn't make sense here. Frankly, repeating this publicly without
relevant context, and avoiding the response you already got, is
inappropriate.

You may call a PMC vote on whether there's even an issue here, sure. If you
pursue it, you should explain specifically what the issue is w.r.t. policy,
and argue against the response you've already received.
We put valid issues in the board report, for sure. We do not include
invalid issues in the board report. That part needs no decision from anyone.


On Fri, Jun 16, 2023 at 3:08 PM Dongjoon Hyun 
wrote:

> No, this is a vote on dev@ intentionally as a part of our previous
> thread, "ASF policy violation and Scala version issues" (
> https://lists.apache.org/thread/k7gr65wt0fwtldc7hp7bd0vkg1k93rrb)
>
> > did you mean this for the PMC list?
>
> I clearly started the thread with the following.
> > - Apache Spark PMC should include this incident report and the result in
> the next Apache Spark Quarterly Report (August).
>
> However, there is a perspective that this is none of Apache Spark PMC's
> role here.
>
> That's the rationale of this vote.
>
> This vote is whether this is Apache Spark PMC's role or not.
>
> Dongjoon.
>

Re: [VOTE] Apache Spark PMC asks Databricks to differentiate its Spark version string

[Dongjoon Hyun]

No, this is a vote on dev@ intentionally as a part of our previous thread,
"ASF policy violation and Scala version issues" (
https://lists.apache.org/thread/k7gr65wt0fwtldc7hp7bd0vkg1k93rrb)

> did you mean this for the PMC list?

I clearly started the thread with the following.
> - Apache Spark PMC should include this incident report and the result in
the next Apache Spark Quarterly Report (August).

However, there is a perspective that this is none of Apache Spark PMC's
role here.

That's the rationale of this vote.

This vote is whether this is Apache Spark PMC's role or not.

Dongjoon.

Re: [VOTE] Apache Spark PMC asks Databricks to differentiate its Spark version string

[Sean Owen]

What does a vote on dev@ mean? did you mean this for the PMC list?

Dongjoon - this offers no rationale about "why". The more relevant thread
begins here:
https://lists.apache.org/thread/k7gr65wt0fwtldc7hp7bd0vkg1k93rrb but it
likewise never got to connecting a specific observation to policy. Could
you explain your logic more concretely? otherwise this is still going
nowhere.


On Fri, Jun 16, 2023 at 2:53 PM Dongjoon Hyun  wrote:

> Please vote on the following statement. The vote is open until June 23th
> 1AM (PST) and passes if a majority +1 PMC votes are cast, with a minimum of
> 3 +1 votes.
>
> Apache Spark PMC asks Databricks to differentiate its Spark
> version string to avoid confusions because Apache Spark PMC
> is responsible for ensuring to follow ASF requirements[1] and
> respects ASF's legal advice [2, 3],
>
> [ ] +1 Yes
> [ ] -1 No because ...
>
> 
> 1. https://www.apache.org/foundation/governance/pmcs#organization
> 2. https://lists.apache.org/thread/mzhggd0rpz8t4d7vdsbhkp38mvd3lty4
> 3. https://www.apache.org/foundation/marks/downstream.html#source
>

Re: [VOTE] Apache Spark PMC asks Databricks to differentiate its Spark version string

[Dongjoon Hyun]

+1

Dongjoon

On 2023/06/16 19:53:03 Dongjoon Hyun wrote:
> Please vote on the following statement. The vote is open until June 23th
> 1AM (PST) and passes if a majority +1 PMC votes are cast, with a minimum of
> 3 +1 votes.
> 
> Apache Spark PMC asks Databricks to differentiate its Spark
> version string to avoid confusions because Apache Spark PMC
> is responsible for ensuring to follow ASF requirements[1] and
> respects ASF's legal advice [2, 3],
> 
> [ ] +1 Yes
> [ ] -1 No because ...
> 
> 
> 1. https://www.apache.org/foundation/governance/pmcs#organization
> 2. https://lists.apache.org/thread/mzhggd0rpz8t4d7vdsbhkp38mvd3lty4
> 3. https://www.apache.org/foundation/marks/downstream.html#source
> 

-
To unsubscribe e-mail: dev-unsubscr...@spark.apache.org

[VOTE] Apache Spark PMC asks Databricks to differentiate its Spark version string

[Dongjoon Hyun]

Please vote on the following statement. The vote is open until June 23th
1AM (PST) and passes if a majority +1 PMC votes are cast, with a minimum of
3 +1 votes.

Apache Spark PMC asks Databricks to differentiate its Spark
version string to avoid confusions because Apache Spark PMC
is responsible for ensuring to follow ASF requirements[1] and
respects ASF's legal advice [2, 3],

[ ] +1 Yes
[ ] -1 No because ...


1. https://www.apache.org/foundation/governance/pmcs#organization
2. https://lists.apache.org/thread/mzhggd0rpz8t4d7vdsbhkp38mvd3lty4
3. https://www.apache.org/foundation/marks/downstream.html#source

Re: ASF policy violation and Scala version issues

[Dongjoon Hyun]

I want to add two updates on this thread.


First, Ammonite library issue is resolved for Scala 2.12/2.13. For Scala 3, we 
can talk later in the scope of Spark 4.

SPARK-44041 Upgrade Ammonite to 2.5.9

This unblocked the following and we start to evaluate them.

SPARK-43832 Upgrade Scala to 2.12.18
SPARK-40497 Upgrade Scala to 2.13.11


Second, Sean, Mitch, and Grisha shared their different perspective on ASF legal 
issue and Apache Spark PMC role in this thread. Thank you again for sharing 
your idea explicitly. I'm going to start a vote for that specifically to build 
a consensus and have a conclusion.


Dongjoon


On 2023/06/12 08:15:39 Dongjoon Hyun wrote:
> Let me add my answers about a few Scala questions, Jungtaek.
> 
> > Are we concerned that a library does not release a new version
> > which bumps the Scala version, which the Scala version is
> > announced in less than a week?
> 
> No, we have concerns about the newly introduced disability
> in the Apache Spark Scala environment.
> 
> 
> 
> > Shall we respect the efforts of all maintainers of open source projects
> > we use as dependencies, regardless whether they are ASF projects or
> > individuals?
> 
> Not only respecting all the efforts, but also Yang Jie and I've been
> participating in those individual projects to help them and us.
> I believe that we've aimed our best collaboration there.
> 
> 
> > Bumping a bugfix version is not always safe,
> > especially for Scala where they use semver as one level down
> > their minor version is almost another's major version
> > (similar amount of pain on upgrading).
> 
> I agree with you in two ways.
> 
> 1. Before adding Ammonite dependency, Apache Spark community itself was one
> of the major Scala users who participated in new version testing and we
> gave active feedback to the Scala community. In addition, we decide whether
> to consume it or not by ourselves. Now, the Apache Spark community has lost
> our ability to consume it because it fails at the dependency downloading
> step. We are waiting because we don't have an alternative. That's a big
> difference; to be able or not.
> 
> 2. Again, I must reiterate that that's one of the reasons why I reported an
> issue, "There is a company claiming something non-Apache like "Apache Spark
> 3.4.0 minus SPARK-40436" with the name "Apache Spark 3.4.0."
> 
> 
> Dongjoon.
> 

-
To unsubscribe e-mail: dev-unsubscr...@spark.apache.org

Re: [VOTE][RESULT] Release Plan for Apache Spark 4.0.0 (June 2024)

[Dongjoon Hyun]

This was a part of the following on-going discussions.

2023-05-28  Apache Spark 3.5.0 Expectations (?)
https://lists.apache.org/thread/3x6dh17bmy20n3frtt3crgxjydnxh2o0

2023-05-30 Apache Spark 4.0 Timeframe?
https://lists.apache.org/thread/xhkgj60j361gdpywoxxz7qspp2w80ry6

2023-06-05 ASF policy violation and Scala version issues
https://lists.apache.org/thread/k7gr65wt0fwtldc7hp7bd0vkg1k93rrb

2023-06-12 [VOTE] Release Plan for Apache Spark 4.0.0 (June 2024)
https://lists.apache.org/thread/r0zn6rd8y25yn2dg59ktw3ttrwxzqrfb

I'm looking forward to seeing the upcoming detailed discussions including the 
following
- Apache Spark 4.0.0 Preview (and Dates)
- Apache Spark 4.0.0 Items
- Apache Spark 4.0.0 Plan Adjustment

Please initiate the discussion.

Thanks,
Dongjoon.


On 2023/06/16 19:30:42 Dongjoon Hyun wrote:
> The vote passes with 6 +1s (4 binding +1s), one -0, and one -1.
> Thank you all for your participation and
> especially your additional comments during this voting,
> Mridul, Hyukjin, and Jungtaek.
> 
> (* = binding)
> +1:
> - Dongjoon Hyun *
> - Huaxin Gao *
> - Liang-Chi Hsieh *
> - Kazuyuki Tanimura
> - Chao Sun *
> - Jia Fan
> 
> -0: Holden Karau
> 
> -1: Xiao Li *
> 

-
To unsubscribe e-mail: dev-unsubscr...@spark.apache.org

[VOTE][RESULT] Release Plan for Apache Spark 4.0.0 (June 2024)

[Dongjoon Hyun]

The vote passes with 6 +1s (4 binding +1s), one -0, and one -1.
Thank you all for your participation and
especially your additional comments during this voting,
Mridul, Hyukjin, and Jungtaek.

(* = binding)
+1:
- Dongjoon Hyun *
- Huaxin Gao *
- Liang-Chi Hsieh *
- Kazuyuki Tanimura
- Chao Sun *
- Jia Fan

-0: Holden Karau

-1: Xiao Li *

Re: [VOTE] Release Plan for Apache Spark 4.0.0 (June 2024)

[Dongjoon Hyun]

Thank you everyone.

I appreciate all your input and conclude this vote.

Dongjoon

On Thu, Jun 15, 2023 at 9:41 AM Hyukjin Kwon  wrote:

> I am supportive of setting the timeline for Spark 4.0, and I think it has
> to be done soon.
> If my understanding is correct, we better need to set up the goals and
> major changes to happen in 4.0.0? That one I agree with too.
> Having a preview sounds good to me too so people can try it out.
>
> Given that all, shall we set down the preview date, major items/targets,
> and 4.0 timeline together in a discussion thread?
> I think we can initiate this discussion, and start a vote again for the
> tentative date.
>
>
> On Fri, 16 Jun 2023 at 00:54, Xiao Li  wrote:
>
>> Since the vote includes the release date for Spark 4.0, I cast my vote as
>> -1, in light of the discussions from the three other PMCs.
>>
>> Also, considering recent discussions on the dev list, numerous breaking
>> changes, such as Scala 2.13, JDK 17 support, and pandas 2.0 support, will
>> be incorporated into Spark 4.0. I propose that we first release a preview
>> so that the entire community can provide more comprehensive feedback before
>> the final release.
>>
>>
>> Jungtaek Lim  于2023年6月12日周一 19:28写道：
>>
>>> I concur with Holden and Mridul. Let's build a plan before we call the
>>> tentative deadline. I understand setting the tentative deadline would
>>> definitely help in pushing back features which "never ever ends", but at
>>> least we may want to list up features and discuss for priority. It is still
>>> possible that we might even want to see some features as hard blocker on
>>> the release for any reason, based on discussion of course.
>>>
>>> On Tue, Jun 13, 2023 at 10:58 AM Mridul Muralidharan 
>>> wrote:
>>>

 I agree with Holden, we should have some understanding of what we are
 targeting for 4.0, given it is a major ver bump - and work from there on
 the release date.

 Regards,
 Mridul

 On Mon, Jun 12, 2023 at 8:53 PM Jia Fan  wrote:

> By the way, like Holden said, what's big feature for 4.0.0? I think
> very big version change always bring some different.
>
> Jia Fan  于2023年6月13日周二 08:25写道：
>
>> +1
>>
>> 
>>
>> Jia Fan
>>
>>
>>
>> 2023年6月13日 03:51，Chao Sun  写道：
>>
>> +1
>>
>> On Mon, Jun 12, 2023 at 12:50 PM kazuyuki tanimura
>>  wrote:
>>
>>> +1 (non-binding)
>>>
>>> Thank you!
>>> Kazu
>>>
>>>
>>> On Jun 12, 2023, at 11:32 AM, Holden Karau 
>>> wrote:
>>>
>>> -0
>>>
>>> I'd like to see more of a doc around what we're planning on for a
>>> 4.0 before we pick a target release date etc. (feels like cart before 
>>> the
>>> horse).
>>>
>>> But it's a weak preference.
>>>
>>> On Mon, Jun 12, 2023 at 11:24 AM Xiao Li 
>>> wrote:
>>>
 Thanks for starting the vote.

 I do have a concern about the target release date of Spark 4.0.

 L. C. Hsieh  于2023年6月12日周一 11:09写道：

> +1
>
> On Mon, Jun 12, 2023 at 11:06 AM huaxin gao <
> huaxin.ga...@gmail.com> wrote:
> >
> > +1
> >
> > On Mon, Jun 12, 2023 at 11:05 AM Dongjoon Hyun <
> dongj...@apache.org> wrote:
> >>
> >> +1
> >>
> >> Dongjoon
> >>
> >> On 2023/06/12 18:00:38 Dongjoon Hyun wrote:
> >> > Please vote on the release plan for Apache Spark 4.0.0.
> >> >
> >> > The vote is open until June 16th 1AM (PST) and passes if a
> majority +1 PMC
> >> > votes are cast, with a minimum of 3 +1 votes.
> >> >
> >> > [ ] +1 Have a release plan for Apache Spark 4.0.0 (June 2024)
> >> > [ ] -1 Do not have a plan for Apache Spark 4.0.0 because ...
> >> >
> >> > ===
> >> > Apache Spark 4.0.0 Release Plan
> >> > ===
> >> >
> >> > 1. After creating `branch-3.5`, set "4.0.0-SNAPSHOT" in
> master branch.
> >> >
> >> > 2. Creating `branch-4.0` on April 1st, 2024.
> >> >
> >> > 3. Apache Spark 4.0.0 RC1 on May 1st, 2024.
> >> >
> >> > 4. Apache Spark 4.0.0 Release in June, 2024.
> >> >
> >>
> >>
> -
> >> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
> >>
>
>
> -
> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
>
>
>>>
>>> --
>>> Twitter: https://twitter.com/holdenkarau
>>> Books (Learning Spark, High Performance Spark, etc.):
>>> https://amzn.to/2MaRAG9  
>>> 

TAC Applications for Community Over Code North America and Asia now open

[Gavin McDonald]

Hi All,

(This email goes out to all our user and dev project mailing lists, so you
may receive this
email more than once.)

The Travel Assistance Committee has opened up applications to help get
people to the following events:


*Community Over Code Asia 2023 - *
*August 18th to August 20th in Beijing , China*

Applications for this event closes on the 6th July so time is short, please
apply as soon as possible. TAC is prioritising applications from the Asia
and Oceania regions.

More details on this event can be found at:
https://apachecon.com/acasia2023/

More information on how to apply please read: https://tac.apache.org/


*Community Over Code North America - *
*October 7th to October 10th in Halifax, Canada*

Applications for this event closes on the 22nd July. We expect many
applications so please do apply as soon as you can. TAC is prioritising
applications from the North and South America regions.

More details on this event can be found at: https://communityovercode.org/

More information on how to apply please read: https://tac.apache.org/


*Have you applied to be a Speaker?*

If you have applied or intend to apply as a Speaker at either of these
events, and think you
may require assistance for Travel and/or Accommodation - TAC advises that
you do not
wait until you have been notified of your speaker status and to apply
early. Should you
not be accepted as a speaker and still wish to attend you can amend you
application to
include Conference fees, or, you may withdraw your application.

The call for presentations for Halifax is here:
https://communityovercode.org/call-for-presentations/
and you have until the 13th of July to apply.

The call for presentations for Beijing is here:
https://apachecon.com/acasia2023/cfp.html
and you have until the 18th June to apply.

*IMPORTANT Note on Visas:*

It is important that you apply for a Visa as soon as possible - do not wait
until you know if you have been accepted for Travel Assistance or not, as
due to current wait times for Interviews in some Countries, waiting that
long may be too late, so please do apply for a Visa right away. Contact
tac-ap...@tac.apache.org if you need any more information or assistance in
this area.

*Spread the Word!!*

TAC encourages you to spread the word about Travel Assistance to get to
these events, so feel free to repost as you see fit on Social Media, at
work, schools, universities etc etc...

Thank You and hope to see you all soon

Gavin McDonald on behalf of the ASF Travel Assistance Committee.