It is definitely his responsibility to explain why he casted -1. He explicitly casted his -1 in DISCUSS and I don't believe I hear anything. The only thing I heard is "users can upgrade Spark 3.5.5 before upgrading to Spark 4.0.0". How do you justify that this is a technical objection while we have heard users' feedback that that is "bad"?
What I heard about "Databricks' mistake" does not back up his proposal. Everyone makes mistakes, and we are mitigating it. Shouldn't we figure out the best way for users rather than blaming who made a mistake? Isn't it the preferred way we do postmortem? I sincerely apologize for being missed on reviewing, if this was needed to smooth the progress. The major argument here is, I (and some others) do not see his justification as "technical objection", so -1 cannot be considered as veto. You also said, "Valid -1 votes are not restricted to technical objections." which makes me super confused. I expect the answer to counter that it is indeed a technical objection. If you really thought it's valid -1 even if it's not having a technical objection, it is obviously not a veto. I'll be happy to wait for his answer. Again, I have 4 questions, and I have to hear everything to be considered that "technical objection" is explained. (You said question 1 is not valid, I'm fine not to hear about it, but we will still have an argument "where" the vendor name could be accepted and where to be disallowed. I said, Apple (not a common noun) is there in the codebase.) On Fri, Mar 14, 2025 at 2:20 PM Mark Hamstra <markhams...@gmail.com> wrote: > It is not Dongjoon's responsibility to clarify ASF policy for you. If > you have ASF policy questions, there are ways to address them through > the PMC, legal and the board, not by making demands on Dongjoon. I > don't presume to speak for the whole PMC as to whether or not having > "spark.databricks" appear in the code is strictly forbidden or not. I > will reassert my opinion that the PMC does have a legitimate interest > in precluding even the appearance that Databricks has any influence or > control over Apache Spark not available to other contributors. I don't > believe that that interest necessarily overrides any Spark user > interests, but it shouldn't be diminished or ignored. > > Please stop trying to claim control over the process, and let's > patiently await Dongjoon's clarification of his technical issues with > the proposal -- or his failure to do so. > > On Thu, Mar 13, 2025 at 10:04 PM Jungtaek Lim > <kabhwan.opensou...@gmail.com> wrote: > > > > And the criteria of justifying -1 must be whether he answered all 4 > questions from me. > > > > https://lists.apache.org/thread/kdtto3poz28q4yrqdqk6839y965sfn5c > > > >> Where is the evidence that having a vendor name in the codebase is > violating ASF policy? Again, I see "Apple" to be used as a vendor name in > the field name. It is definitely not used as a common noun. What's your > call on this? Why do we keep saying where there is evidence and we don't > see any? Why didn't you just say we must remove the migration logic the > first time we talked about this (unlike you did say there are "two" > approaches, link < > https://github.com/apache/spark/pull/49983#issuecomment-2676531485>)? > This is a major issue for me as you gave false hope that you seem to think > option 1 is also a valid one, and I thought I can persuade you as long as I > show you people's opinion. Why is it OK to ship the migration logic in > Spark 3.5.5+ in Spark 3.5.x line if you think this is really bad? I don't > think it's really a long time to make the effort of upgradability to take > effect. Will we ever release Spark 3.5.20 or so? Why do you think your > approach doesn't need to pass with VOTE, while in this VOTE you are the > only one disagreeing with the other approach? Is it just that the current > code is automatically achieving your goal? I believe this makes no sense. > > > > > > I believe the last one is the most important one to hear, but I argue we > should say we don't hear about the justification if he doesn't answer any > of them. > > > > > > On Fri, Mar 14, 2025 at 1:51 PM Mark Hamstra <markhams...@gmail.com> > wrote: > >> > >> Again, we have not spent 3 weeks on the matter at hand: whether > >> Dongjoon's veto is valid. Please stop asserting irrelevant timeframes > >> and extraneous issues. > >> > >> The end of this week appears more than adequate and fair to me. > >> > >> On Thu, Mar 13, 2025 at 9:46 PM Jungtaek Lim > >> <kabhwan.opensou...@gmail.com> wrote: > >> > > >> > I love to hear what is the reasonable time here. If you say 1 week, > it doesn't make sense at all. So what time do you suggest on the deadline? > Will you be fine by the end of this week? > >> > > >> > Don't leave the status to be ambiguous. We already spent 3 weeks > there. I don't want to let this be dragged. > >> > > >> > On Fri, Mar 14, 2025 at 1:37 PM Mark Hamstra <markhams...@gmail.com> > wrote: > >> >> > >> >> The relevant time window is since Dongjoon's veto was challenged, not > >> >> any other that you choose to assert. It has been less than a day > since > >> >> that challenge. > >> >> > >> >> Dongjoon presented a prima facie correct veto to the proposal. The > >> >> technical justification he gave was challenged or asserted to be > >> >> invalid. We should either see his response to the challenge or at > >> >> least wait a reasonable time for that response before declaring the > >> >> veto invalid. > >> >> > >> >> On Thu, Mar 13, 2025 at 8:43 PM Jungtaek Lim > >> >> <kabhwan.opensou...@gmail.com> wrote: > >> >> > > >> >> > I am open to waiting for a day, but please be sure to remember > that 3 weeks have passed and he had plenty of time to persuade people like > I did. > >> >> > > >> >> > Also, I'd like to remind you that I did not attempt "just one > time" to get his voice (yeah, persuade, actually). > >> >> > > >> >> > This is the post I sent to ask for revisiting the decision. > >> >> > https://lists.apache.org/thread/v35ld522hgtsrghfzkbk8bhf6sopw1kn > >> >> > > >> >> > This is what I got. > >> >> > https://lists.apache.org/thread/ty8svwbp7hqqd325dhd0gohxrpybd2fk > >> >> > > >> >> > I don't see the feedback to be something that leads to productive > discussion. I feel like discussion is just blocked. > >> >> > > >> >> > My greatest worry is, we might be in a situation where we have > another cycle of discussion/debate based on his feedback. We have 3 week > already and I think I got users' feedback as well. The people who will be > hitting this are users, not contributors, committers, and PMC members. Even > PMC members need to respect users. That's what the project is for. Likewise > veto, PMC members can't override it. > >> >> > > >> >> > > >> >> > On Fri, Mar 14, 2025 at 12:26 PM Mark Hamstra < > markhams...@gmail.com> wrote: > >> >> >> > >> >> >> Characterizing Dongjoon's position as just "agree to disagree" > without > >> >> >> any valid technical issue is your position. I have not seen any > >> >> >> endorsement from him on list that this is a correct > characterization > >> >> >> of his position. > >> >> >> > >> >> >> I see recent questioning of whether Dongjoon's veto is justified > by a > >> >> >> valid technical issue. I see no response yet to that challenge. > There > >> >> >> is little to no harm in giving him some more time to respond to > the > >> >> >> recent challenge to his veto. > >> >> >> > >> >> >> > >> >> >> On Thu, Mar 13, 2025 at 8:17 PM Jungtaek Lim > >> >> >> <kabhwan.opensou...@gmail.com> wrote: > >> >> >> > > >> >> >> > Actually, this has been initially triggered from 3 weeks ago, > not just a week we have spent. > >> >> >> > > https://github.com/apache/spark/pull/49983#issuecomment-2676531485 > >> >> >> > > >> >> >> > Mark, do you still want me to persuade Dongjoon while I clearly > saw his stance on this on the VOTE thread? He can correct me, but from what > I understand, he just wanted to leave the status to "agree to disagree", > and I'm OK with that as long as I'm not blocked. > >> >> >> > > >> >> >> > We have asked about the rationale of being against the > proposal, like, what is the ASF policy he is referring to. I don't hear > anything. It's not just happen in a day or so, and I think he had enough > time to discuss it with us if he wanted to persuade the others, like, > influencing the opposite direction. > >> >> >> > > >> >> >> > On Fri, Mar 14, 2025 at 11:58 AM Sean Owen <sro...@gmail.com> > wrote: > >> >> >> >> > >> >> >> >> This has been ongoing for a week, the vote has been open for 3 > days, Dongjoon has replied today (not sure if you saw it), and I think this > is all around in circles; I don't see any basis for waiting 24 hours (? > where is this from?) I don't know if this is a code change vote - there is > no code changing. But if it were, I think everyone's still missing the > technical justification part, so, same result. I think this is definitely > the correct result by spirit and letter of policy. > >> >> >> >> > >> >> >> >> It's not like we can't all change minds if some new legitimate > concern or angle comes out, but, I'd say it's better not to keep > entertaining this conversation if there is no movement on the substance of > the discussion. There is just clear support for the position in this vote. > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> On Thu, Mar 13, 2025 at 9:42 PM Mark Hamstra < > markhams...@gmail.com> wrote: > >> >> >> >>> > >> >> >> >>> This vote has not passed. > >> >> >> >>> > >> >> >> >>> The proposed code change has been vetoed by a qualified > voter. The > >> >> >> >>> validity of that veto has been called into question since > "the voter > >> >> >> >>> must provide with the veto a technical justification showing > why the > >> >> >> >>> change is bad (opens a security exposure, negatively affects > >> >> >> >>> performance, etc. )." It has been less than 24 hours since > Dongjoon's > >> >> >> >>> veto was called into question. He should be given a chance to > explain > >> >> >> >>> why there is technical justification for it. > >> >> >> >>> > >> >> >> >>> On Thu, Mar 13, 2025 at 7:21 PM Jungtaek Lim > >> >> >> >>> <kabhwan.opensou...@gmail.com> wrote: > >> >> >> >>> > > >> >> >> >>> > The vote passes with 7 +1s (3 binding +1s) and 1 -1s (1 > binding -1s). > >> >> >> >>> > Thanks to all who helped with the vote! > >> >> >> >>> > > >> >> >> >>> > I'm going to make a code change in branch-4.0 quickly so > that we don't have to trigger another RC for Spark 4.0.0 just because of > this. > >> >> >> >>> > > >> >> >> >>> > (* = binding) > >> >> >> >>> > +1: > >> >> >> >>> > - Sean R. Owen * > >> >> >> >>> > - Jungtaek Lim > >> >> >> >>> > - Nicholas Chammas > >> >> >> >>> > - Wenchen Fan * > >> >> >> >>> > - Adam Binford > >> >> >> >>> > - Russell Jurney > >> >> >> >>> > - Yang Jie * > >> >> >> >>> > > >> >> >> >>> > -1: > >> >> >> >>> > - Dongjoon Hyun * > >> >> >> >>> > > >> >> >> >>> > Thanks, > >> >> >> >>> > Jungtaek Lim (HeartSaVioR) > >> >> >> >>> > >> >> >> >>> > --------------------------------------------------------------------- > >> >> >> >>> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org > >> >> >> >>> > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org > >> >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org > >> > > --------------------------------------------------------------------- > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org > >
