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.
>>
>>
