To summarize, the main arguments of both proposals are "whether we can force users to upgrade to Spark 3.5.5 first before upgrading Spark 4.0.0" vs "we should include migration logic to Spark 4.0.0 because that is not realistic". Where is the "technical objection" here? If you say there was politics I can clearly say never, but even if you interpret there was politics, politics is not "technical objection". I can quote the relevant ASF page for you.
https://www.apache.org/foundation/voting.html#Veto > A -1 vote by a qualified voter stops a code-modification proposal in its tracks. This constitutes a veto, and it cannot be overruled nor overridden by anyone. Vetoes stand until and unless the individual withdraws their veto. > To prevent vetoes from being used capriciously, the voter must provide with the veto a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, etc. ). A veto without a justification is invalid and has no weight. The justification must be "technical one" for vote. I hope ASF just lists the most cases rather than leaving this as etc, but I think ASF believes individual's judgement, and I claim there is no "technical reason". Having to put 4 more lines is never a technical reason. It is never meant to be used for blocking different opinions. It must be used for blocking "incidents which impact users", while we are here to do the opposite, saving users' life. On Sat, Mar 15, 2025 at 9:51 PM Jungtaek Lim <kabhwan.opensou...@gmail.com> wrote: > > That's the reason why you proposed the vote procedure and we agreed. > > Didn’t you see the part “we agreed”? Who is we in the context? > > I don’t think he answered my questions - he explained his reasoning of his > proposal which majorly does not agree with. You even said uou are not > persuaded and I want to ask you now you were persuaded from his last post. > > Again I haven’t heard my answers. He showed his reasoning but there is > nothing about the evidence of the validity of “technical” objection. I > think I have asked people who judged his -1 as veto for their reasoning of > how this could be “technical” objection and I don’t think I heard anything. > > I can be corrected if you can point out what is the “technical” objection. > If you or Dongjoon do not provide this to the end of the week, I have to > consider I haven’t heard about that and the veto (although Dongjoon stated > it is not a veto) will be ignored. > > 2025년 3월 15일 (토) 오후 8:19, Mark Hamstra <markhams...@gmail.com>님이 작성: > >> Once again, I have to object. Dongjoon said that the vote is a time >> limited procedure, not that the vote itself is a procedural vote as >> distinct from a code change vote or a package release vote. >> >> Frankly, this feels like you are trying to manipulate the vote >> procedure by misrepresenting Dongjoon, and you are quickly losing my >> confidence in your ability to administer a fair voting procedure. >> >> I still consider the proposal to be vetoed. >> >> >> On Fri, Mar 14, 2025 at 6:11 PM Jungtaek Lim >> <kabhwan.opensou...@gmail.com> wrote: >> > >> > UPDATE: >> > >> > We were having a discussion about the type of VOTE, since Dongjoon's -1 >> should be considered as a veto if we see this as a code change VOTE. >> > Dongjoon clarified that he does not see this VOTE as a code change, >> hence he gave -1 but not intended to block the VOTE. >> > >> > That said, we have confirmed that Dongjoon's -1 is not a veto. I think >> the VOTE result is correct as it is. I'll proceed with the next steps. >> > >> > On Fri, Mar 14, 2025 at 11:19 AM 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 >> >>
