You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@spark.apache.org by GitBox <gi...@apache.org> on 2022/08/11 16:10:11 UTC

[GitHub] [spark] dongjoon-hyun commented on pull request #37293: [SPARK-39872][SQL] Change to use `BytePackerForLong#unpack8Values` with Array input api in `VectorizedDeltaBinaryPackedReader`

dongjoon-hyun commented on PR #37293:
URL: https://github.com/apache/spark/pull/37293#issuecomment-1212195954

   Thank you, @sadikovi. I believe we are going to have a best way in the end like your suggestions (another code path and flags). Could you make a contribution for that by yourself if you can? 😄 
   
   BTW, I just want to point out some concerning two specific reasoning and perspectives in the discussion thread.
   
   First, in the following comment, may I ask why it is good for for Apache Spark, @sadikovi ? As we know, the unknown downstream forks can do everything except blocking the Apache Spark repository because Apache Spark community is deserved to have the best of bests for the community instead of the worst of the worsts. Apache Spark repository is unable to be responsible for unknown downstream activity if you cannot make a contribution back.
   
   > People use different parquet-mr versions with Spark so it would be good to either have a constraint/error so they know what went wrong or have some kind of general way of handling things.
   
   Second, for the following, unfortunately, I would cast my veto to those kind of reverting PRs whose purpose and benefit is unclear in the community. In general, as a reviewer comment from some contributor to another contributor, the following sentence looks too aggressive and is not the best way. There is a better way to do the same thing. You can ping those committers you want to ping to get more feedbacks. That is welcome and a better Apache Spark Way.
   > I don't think it has anything to do with the current codebase, not the Spark one anyway. It would be up to committers to revert
   
   BTW, I fully understand what you meant in general here and again I believe we can able to build the best Apache Spark for the whole community while keeping consistency and minimizing burdens with your downstream forks.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org