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