Re: [RESULT][VOTE] Technical Justification for the veto of the "Retain migration logic..." code change proposal is not valid

As you noted previously, this does allow the original vote to proceed without a valid veto, but I will also note that this does not preclude modifying the migration logic later to avoid explicitly including “databricks” in the code if people think that is important and an agreeable, technically sou

RE: Re: [Discuss] SPIP: Support NanoSecond Timestamps

Thank you all for your comments and suggestions! Let me rewrite the document. On 2025/03/17 22:28:35 Gengliang Wang wrote: > Hi Qi, > > Thanks for the proposal. I am generally +1 with the idea. Could you clarify > which option is preferred in “Q1. What are you trying to do?”? > Understanding this

Re: [Discuss] SPIP: Support NanoSecond Timestamps

IMHO that’s not a good comparison. By that logic we shouldn’t have double because it’s slower than int. We should compare against the competition first. Maybe as part of this effort we’ll need to prototype two competing solutions. The vast majority of differences should be related to storage cos

Re: [VOTE] Technical Justification for the veto of the "Retain migration logic..." code change proposal is not valid

I would like to conclude this vote with my own -1, for the same reasons as Holden. Personally, I feel that this approach has been overly excessive in several ways - such as overriding a veto - and it would have been better to explore alternative solutions first. That said, it seems that this vote h

Re: [Discuss] SPIP: Support NanoSecond Timestamps

Hi Qi, Thanks for the proposal. I am generally +1 with the idea. Could you clarify which option is preferred in “Q1. What are you trying to do?”? Understanding this will help us align our discussion. On Mon, Mar 17, 2025 at 3:05 PM Reynold Xin wrote: > Pretty much anything (say vs current tim

Re: [Discuss] SPIP: Support NanoSecond Timestamps

Pretty much anything (say vs current timestamp operations in Spark). On Mon, Mar 17, 2025 at 2:51 PM serge rielau.com wrote: > What are you comparing performance against? > On Mar 17, 2025 at 11:54 AM -0700, Reynold Xin , > wrote: > > Any thoughts on how to deal with performance here? Initially

Re: [Discuss] SPIP: Support NanoSecond Timestamps

What are you comparing performance against? On Mar 17, 2025 at 11:54 AM -0700, Reynold Xin , wrote: Any thoughts on how to deal with performance here? Initially we didn't do nano level precision because of performance (would not be able to fit everything into a 64 bit int). On Mon, Mar 17, 2025

Re: [VOTE] Technical Justification for the veto of the "Retain migration logic..." code change proposal is not valid

+1 I would like to add my perspective to this discussion. It's important that we maintain a fair and objective technical evaluation process, especially when a veto is cast. A veto should be backed by concrete technical reasoning. >From my reading of the discussion, the key concern is whether the

Re: [Discuss] SPIP: Support NanoSecond Timestamps

Any thoughts on how to deal with performance here? Initially we didn't do nano level precision because of performance (would not be able to fit everything into a 64 bit int). On Mon, Mar 17, 2025 at 11:34 AM Sakthi wrote: > +1 (non-binding) > > On Mon, Mar 17, 2025 at 11:32 AM Zhou Jiang > wrot

Re: [Discuss] SPIP: Support NanoSecond Timestamps

+1 (non-binding) On Mon, Mar 17, 2025 at 11:32 AM Zhou Jiang wrote: > +1 for the nanosecond support > > > > On Mar 16, 2025, at 16:03, Dongjoon Hyun wrote: > > > > +1 for supporting NanoSecond Timestamps. > > > > Thank you, Qi. > > > > Dongjoon. > > > >

Re: [Discuss] SPIP: Support NanoSecond Timestamps

+1 for the nanosecond support > On Mar 16, 2025, at 16:03, Dongjoon Hyun wrote: > > +1 for supporting NanoSecond Timestamps. > > Thank you, Qi. > > Dongjoon. > > - > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org

Re: Code formatting tech debt

Thanks for the reply. I was following the developer tools wiki that suggests using scalafmt. I checked ./dev/lint-scala and it is a wrapper around scalafmt for some modules like you suggested. Is there a recommendation for auto-formatting and enforcem

Re: [VOTE] Technical Justification for the veto of the "Retain migration logic..." code change proposal is not valid

Before I cast my vote here, I'd like to highlight one thing: As the release manager of Apache Spark 4.0.0, I was not notified about the breaking change of renaming an already-released configuration: https://github.com/apache/spark/pull/49897 . Note that the previous VOTE from Dongjoon was about Apa

Unsubscribe

Unsubscribe

Unsubscribe

[PROPOSE] Fix the procedural steps on the incorrect config fixes

Hi, I want to flip this discussion to NOT talk about anything we are debating in VOTE, but talk about the "abnormal process" being done with my migration logic PRs, and propose to fix it. Here is the timeline: 1. We merged the PR to "remove" the incorrect SQL config to master/4.0, "with the conce

Re: [DISCUSS] New Spark Connect Client repository for Swift language

Hey Dongjoon, You're absolutely free to do whatever you please and see fit. When we had the previous discussion on the Go repository, many folks chimed in and indicated that using the issues feature in GitHub lowers the barrier of entry for contributors to the client library. The idea behind this

Unsubscribe

Unsubscribe

Unsubscribe