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

[Mich Talebzadeh]

Sorry I believe I opinionated on it but did not vote.

-1 for me

For reasons already brought up and discussed.

HTH

Mich Talebzadeh,
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 Thu, 22 Jun 2023 at 16:39, Dongjoon Hyun  wrote:

> Thank you, Sean, Mitch, Hyukjin, and Maciej for your participation.
>
> The vote is open until June 23rd 1AM (PST) and I'll conclude this vote
> after that.
>
> Dongjoon.
>
> PS. Steve's email seems to arrive to this thread mistakenly. :)
>
>
>
> On Wed, Jun 21, 2023 at 3:12 AM Steve Loughran 
> wrote:
>
>> I'd say everyone should *and* http UA in all the clients who make calls
>> of object stores should, as it helps field issues there. s3a and abfs
>> clients do provide the ability to add params there -please set them in your
>> deployments
>>
>> On Fri, 16 Jun 2023 at 21:53, 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]

Thank you, Sean, Mitch, Hyukjin, and Maciej for your participation.

The vote is open until June 23rd 1AM (PST) and I'll conclude this vote
after that.

Dongjoon.

PS. Steve's email seems to arrive to this thread mistakenly. :)



On Wed, Jun 21, 2023 at 3:12 AM Steve Loughran 
wrote:

> I'd say everyone should *and* http UA in all the clients who make calls of
> object stores should, as it helps field issues there. s3a and abfs clients
> do provide the ability to add params there -please set them in your
> deployments
>
> On Fri, 16 Jun 2023 at 21:53, 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

[Steve Loughran]

I'd say everyone should *and* http UA in all the clients who make calls of
object stores should, as it helps field issues there. s3a and abfs clients
do provide the ability to add params there -please set them in your
deployments

On Fri, 16 Jun 2023 at 21:53, 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

[Maciej]

+0

A PMC member raised a justified concern regarding the Apache Spark 
trademark usage. Based on the linked discussion on @legal, that opinion 
seems to be weakly supported by the ASF Legal Affairs Assistant V.P.


As such, it shouldn't just be rejected, especially not because of our 
preference for discussion to be held in private or because it doesn't 
address a general case. In fact, given the special role that the alleged 
violator has in the project community (and a low potential for harm), we 
might prefer it to be public to avoid accusations of bias and conflicts 
of interest, although it is worth pointing out that it goes against an 
explicit ASF policy 
(https://www.apache.org/foundation/marks/reporting.html):


"It is a best practice to use the private@/projectname/.apache.org 
mailing list to discuss any reports of potential infringement first"


However, in the case of any trademark, license, or contract violation, 
it is important not only to establish that there is a legal basis for 
action but also to document the actual harm that it causes.  For 
trademark violations, we're cornered primarily with customer (user) 
harm, and it hasn't been shown here or in the other thread that such a 
risk exists.


That being said, PMC asking a company to clearly indicate a modified 
version of the software is a soft action considering the alternative 
(passing the case to the ASF branding), which we are required to use in 
case a polite request fails.


On 6/19/23 06:59, Hyukjin Kwon wrote:
With the spirit of open source, -1. At least there have been other 
cases mentioned in the discussion thread, and solely doing it for one 
specific vendor would not solve the problem, and I wouldn't also 
expect to cast a vote for each case publicly.
I would prefer to start this in the narrower scope, for example, 
contacting the vendor first and/or starting from a private mailing 
list instead of publicly raising this in the dev mailing list.



On Sat, 17 Jun 2023 at 07:22, Dongjoon Hyun  
wrote:


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 

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

[Hyukjin Kwon]

With the spirit of open source, -1. At least there have been other cases
mentioned in the discussion thread, and solely doing it for one specific
vendor would not solve the problem, and I wouldn't also expect to cast a
vote for each case publicly.
I would prefer to start this in the narrower scope, for example, contacting
the vendor first and/or starting from a private mailing list instead of
publicly raising this in the dev mailing list.


On Sat, 17 Jun 2023 at 07:22, Dongjoon Hyun  wrote:

> 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

[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