I agree with Holden regarding Spark 4 being the perfect time to drop this configuration.
El sáb, 15 mar 2025, 22:33, Holden Karau <holden.ka...@gmail.com> escribió: > My $0.02: > > I do not believe that this vote has passed. I believe there is a valid > veto. On a personal level from a migration point of view I think Spark 4 is > the perfect time to drop this configuration. > > Given the disagreement of if this is a valid veto I think we should pause > until the board has been given time to provide its input. > > Previous perceived dismissing of committer and PMC input has resulted in > this being a more sensitive topic in this project than perhaps some others. > > How do folks feel about writing up their views for the board sending it > over to them and seeing if they want to provide input? > > Twitter: https://twitter.com/holdenkarau > Fight Health Insurance: https://www.fighthealthinsurance.com/ > <https://www.fighthealthinsurance.com/?q=hk_email> > Books (Learning Spark, High Performance Spark, etc.): > https://amzn.to/2MaRAG9 <https://amzn.to/2MaRAG9> > YouTube Live Streams: https://www.youtube.com/user/holdenkarau > Pronouns: she/her > > > On Sat, Mar 15, 2025 at 1:38 PM Mich Talebzadeh <mich.talebza...@gmail.com> > wrote: > >> This is my gist >> >> Mark from your passionate language I gather you see this as a "Code >> Change" veto. Your reasoning seems to be straightforward, i.e. the vote's >> purpose is to decide whether to add code (migration logic) to the Spark 4.0 >> branch. In your view, the outcome of the vote directly alters the >> software's code? >> >> However, If we see it as a *procedural matter only* like some others >> include myself, it involves a vote and the interpretation of rules. >> >> In summary >> >> 1. If it is a code change vote, a -1 can be seen as a veto, blocking >> the change unless specific conditions are met (like the PMC overriding the >> veto). >> 2. If it is just a procedural vote, a -1 might simply be a dissenting >> vote, *not necessarily carrying the power to block the entire action.* >> >> FYI, I recall I voted -1 (non binding) on another thread and >> Dongioon asked me to explain which it was in his right >> >> I can see the following vote cast (1) >> >> - Jungtaek Lim: +1 (non-binding) >> - Sean Owen: +1 to retain >> - Yang Jie: -1, later withdraws it and casts +1 >> - Adam Binford: +1 (non-binding) >> - Russell Jurney: +1 non-binding >> - Yang Jie: +1 >> - Mridul Muralidharan: +1 >> - Dongjoon Hyun: -1 >> >> >> *(1) Summary of Voting from 21 emails in the attached file* from >> https://lists.apache.org/thread/nm3p1zjcybdl0p0mc56t2rl92hb9837n : >> >> For Retaining Migration Logic (+1): Jungtaek Lim, Sean Owen, Yang Jie >> (initially -1, then +1), Adam Binford (non-binding), Russell Jurney >> (non-binding), Mridul Muralidharan >> Against Retaining Migration Logic (-1): Dongjoon Hyun >> >> Maybe we should put a bar on it and allow Dongjoon to qualify his >> statement as 1 or 2 above, thern it could be escalated if needed or put at >> rest >> >> HTH >> >> >> >> >> >> On Sat, 15 Mar 2025 at 18:26, Mark Hamstra <markhams...@gmail.com> wrote: >> >>> That is utter nonsense, Sean! You do not have any authority to declare >>> the matter concluded, and I will escalate to the board if you persist >>> in this approach. >>> >>> The proposed code change has been vetoed. As I delineated previously, >>> there are two and only two ways forward under the ASF Voting Process. >>> That does not include any individual simply declaring that the matter >>> has been concluded regardless of the veto and ASF process. >>> >>> On Sat, Mar 15, 2025 at 11:18 AM Sean Owen <sro...@gmail.com> wrote: >>> > >>> > 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 >>> >> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org > >
