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