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 <dongjoon.h...@gmail.com> 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 <sro...@gmail.com> wrote: > >> On Fri, Jun 16, 2023 at 3:58 PM Dongjoon Hyun <dongjoon.h...@gmail.com> >> 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. >> >>
