PHILO-HE commented on code in PR #10659:
URL:
https://github.com/apache/incubator-gluten/pull/10659#discussion_r2339435788
##########
backends-velox/src/main/scala/org/apache/gluten/config/VeloxConfig.scala:
##########
@@ -538,6 +538,7 @@ object VeloxConfig {
val VELOX_BROADCAST_BUILD_RELATION_USE_OFFHEAP =
buildConf("spark.gluten.velox.offHeapBroadcastBuildRelation.enabled")
.internal()
+ .experimental()
Review Comment:
Thanks for your reply. My point is we should establish a clear convention to
developers and users. It may sound good to make internal and experimental
independent.
We can view internal configs as those intended for developers or advanced
users only. They can also be experimental—for example, some unstable tracing
configs for debugging can be experimental. On the other hand, not all
experimental configs are internal. If they can be exposed to end users for
early evaluation even though still under experimental, they shouldn't be marked
as internal.
Possible rule
1. Public/internal: Who should see/use it
2. Experimental: How reliable it is (can be marked as either public or
internal based on the first item)
Based on this rule, many experimental configs can be marked as public if
they can be exposed to end users.
If this makes sense, we need to update the comments for the internal API,
where experimental configs are previously viewed as internal always. And we
also need to note that some experimental configs may fall under public category
and some under internal category. Then, I feel it may be not good to have a
dedicated section to document experimental configs, considering possible
duplication. Instead, it may be better to just keep two sections in document:
public and internal.
Actually, I am not quite sure which convention is clearer to users and
developers. It seems always putting experimental in internal category is
clearer? Discussion is welcome. Thanks.
--
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]
