Mark et al - this thread has gone on way too long. Everyone has expressed their opinion. The result stands. Anyone who is really upset about it, please escalate to the board or something, but, this thread and decision point has now concluded.
On Sat, Mar 15, 2025 at 1:16 PM Mark Hamstra <markhams...@gmail.com> wrote: > 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 > >
