pan3793 commented on PR #52641:
URL: https://github.com/apache/spark/pull/52641#issuecomment-3420610110

   > Adding a legacy configuration appears contradictory under the hypothesis 
of non-breaking changes.
   
   @yaooqinn I hold the same view, I prefer to not have config, but if someone 
want, I'm also fine to have an internel config.
   
   > This seems inappropriate for the community to make any assumptions on 
their behalf.
   
   I'm not fully agree with this. It's a fact that there are many vendors have 
their own Spark distributions, if possible, we should make code vendor-friendly 
if it won't introducing additional complexity.
   
   Consider some common practice for vendors: the vendor usually has their own 
support channel, version suffix, docs site. In history, 
   
   - SPARK-41134 changed the internal error message from `... fill a bug report 
in ...` to `... report this bug to the corresponding communities or vendors, 
and provide the full stack trace.`
   - SPARK-42249 put the `spark_doc_root` into `spark-version-info.properties` 
instead of hard coding, which also simplified vendor for customize.
   
   > Or if it's for Spark code contributors for bug hunting, version w/-or-w/o 
can still be vague. Instead, they should refer to the git hashtag.
   
   I agree git hash is more accurate, but full version is still valuable in 
many cases. For example, if there is a well known bug in `Foo Spark 
3.2.1-foo1.2.3`, it's easy to justify with  a full version. And if user runs 
Spark SQL in an access-limited env, without allowing sharing screenshoot or 
copy-pasting, when they hit issues and asking for help publicly, the git hash 
is likely not being included in the provided version info.
   


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to