hi Micah, I agree that documenting the maturity of components is a good idea.
The discussion in ARROW-6206 contains some mildly offensive language directly at the Arrow community, like "arrow is a team that picked up netty derived off-heap tools naively". Excuse me? Documentation aside, I think such language runs afoul of our code of conduct (https://www.apache.org/foundation/policies/conduct). We're at a stage of project maturity where we are going to start to see more users with 0 contributions to the project complaining about various things. So we can do things to head off those complaints but we shouldn't allow people from outside the community decide what standards we need to hold ourselves to. - Wes On Wed, Aug 21, 2019 at 2:02 AM Micah Kornfield <emkornfi...@gmail.com> wrote: > > A recent issue with the JDBC adapter [1] made me realize we aren't doing > enough to communicate to consumers the maturity of various modules within > arrow. From the issue, it also seems like it is surprising that everything > is based off of off-heap data access. > > To help with this I added a description to each module in a new PR [2] with > a preliminary annotation experimental/contrib [3] modules. The annotations > match my understanding of the current state of the world, but please > correct them if I got something wrong. > > If anyone knows how tags on mvnrepository [4] are generated, I think it > would also be good to populate tags for experimental, contrib and > off-heap/nio code. > > Is there anything else we could be doing? > > Thanks, > Micah > > [1] https://issues.apache.org/jira/browse/ARROW-6206 > [2] https://github.com/apache/arrow/pull/5151 > [3] My rough definitions for each annotation are: > 1. Contrib - Limited users, not well tested in production > environments. Not necesserily optimized. > 2. Experimental - Not finalized (very likely to be breaking API > changes). > Better definitions are welcome :) > [4] https://mvnrepository.com/artifact/org.apache.arrow/arrow-vector
