Add notice on mainenance bandwidth to readme

[alamb]

Closes #1429

This PR clarifies for current and potential future users that the current maintenance bandwidth for this crate is very limited. Related to @tustvold 's proposal on #1464

I also hope it might encourage other current users of arrow2 to offer to help maintain the crate if that is valuable to them.

[codecov]

Codecov Report

Patch coverage has no change and project coverage change: +0.01 🎉

Comparison is base (07fd3f6) 83.70% compared to head (e7b55fd) 83.72%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1476      +/-   ##
==========================================
+ Coverage   83.70%   83.72%   +0.01%     
==========================================
  Files         389      389              
  Lines       41775    41775              
==========================================
+ Hits        34969    34975       +6     
+ Misses       6806     6800       -6     

see 3 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[ritchie46]

Hey Andrew. Thanks for the PR. I think I can find myself more in this. I am / Polars is willing to maintain arrow2 as it is a huge dependency for us. If we can work out a way to get the API working on arrow-rs, I might consider a switch, but the capacity is not here at the moment.

I think you can mention that development here is slower paced than on arrow-rs. I am definitely willing to fix bugs as I encounter them though. I think that only the development of new features is rather stalled.

[alamb]

Hey Andrew. Thanks for the PR. I think I can find myself more in this. I am / Polars is willing to maintain arrow2 as it is a huge dependency for us.

I see -- I didn't realize you planned to maintain arrow2. If that is the case then such a maintenance notice may not necessary. 🤔

I think you can mention that development here is slower paced than on arrow-rs. I am definitely willing to fix bugs as I encounter them though. I think that only the development of new features is rather stalled.

I took at shot at updating the wording -- given my position and effort on arrow-rs I don't think it would be appropriate for me to offer opinions on the relative speed of the repositories in arrow2 so I just said "had more maintenance capacity" which seemed less potentially negative.

Given I don't really know what your plans are maybe we should just close this PR as not helpful.

[ritchie46]

Given I don't really know what your plans are maybe we should just close this PR as not helpful.

Yes, I don't think it per se helps much. :) I will close this and reconsider it once/if we are further in the transition process. Let's wait out a bit.

[alamb]

It appears the maintenance status of arrow2 is still causing some confusion:

https://lists.apache.org/thread/184bg72yntrblo0cbnofmnzpx6m28thq

[ritchie46]

Yeap, it's on my stack. :)

[mnpw]

@ritchie46 I noticed the addition of nano-arrow crate to polars (pola-rs/polars#11179). Does this mean that arrow2 will receive low maintenance bandwidth going forward? If so then perhaps we can re-open this PR and update the readme.

[alamb]

In case anyone else finds this issue:

I believe that pola-rs is vendoring (aka brought a snapshot of the arrow2 code into their codebase):

• arrow2 nano-arrow pola-rs/polars#11179
• parquet2 chore(rust): inline parquet2 pola-rs/polars#12026

[ritchie46]

Yes, @alamb is correct, we started vendoring in polars and repelling anything we don't use. See our notice here: pola-rs/polars#11179

[alamb]

Related discussion: #1429