There is not clear support for the position in this vote. There is a clear effort to veto by Dongjoon. He provided some technical justification with his -1 vote. That justification has been called into question. We have not yet seen his response to that, and it has been less than 24 hours.
Frankly, the appearance that Databricks employees are trying to diminish issues and to ramrod a vote is very much of a piece with the non-technical concern associated with this issue. When it comes to Spark, Databricks is unquestionably in a unique position not shared by any other vendor, so saying that other vendor names appear in the codebase is at least not dispositive on the issue of whether "spark.databricks" can be tolerated in the Apache Spark codebase. The PMC does have a legitimate interest in preventing even the appearance that Databricks is being given any preferential treatment or control over the Apache Spark project. That by itself is not a technical issue, and has to be weighed against user technical interests. I'm not convinced of Dongjoon's technical objection, but he does deserve a realistic chance to respond to the asserted rejection of his veto. That is not too much to ask, nor are we facing a strict timeline that demands an immediate conclusion to the vote. On Thu, Mar 13, 2025 at 7:57 PM 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
