You do not have the authority to declare Dongjoon's technical justification invalid. That is up to the PMC: "In case of doubt, deciding whether a technical justification is valid is up to the PMC."
On Sat, Mar 15, 2025 at 6:20 AM Jungtaek Lim <kabhwan.opensou...@gmail.com> wrote: > > 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 >>> --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
