Discussion about maintainability

[TennyZhuang]

Thank you very much for this crate. I have been looking forward to it for a long time. For databases, runtime Ord is very important. I've also initiated a related PreRFC on rust-internals, but there was no follow-up.

For the attempt of porting std BTreeMap into an independent crate, I have also considered it before, but I have some concerns about upstream compatibility. I would like to discuss it here.

How do we maintain the crate if we think it is always a distribution of std and needs to be fully consistent with upstream except for the TotalOrder extension? There are some common ideas.

1. Record the files we have patched very carefully, and always cherry-pick commits from upstream. In this solution, we should try to modify only the smallest set of files possible and attempt to semi-automatically obtain updates from upstream.
2. Make it great and let it serve as an implementation for std BTreeMap references, just like hashbrown.
3. Just borrowing the existing implementation of std BTreeMap and maintaining it independently later, which would likely take up a lot of effort.

[eggyal]

This has been something that I've been concerned about since the beginning, so I'm really pleased someone has opened up the discussion for other ideas to be considered.

Currently, I'm sort of doing your first suggestion: I use git subtree split with a few explicitly defined paths to track upstream changes and automatically open pull requests in this repo; I then manually perform a subtree merge from that automated PR, making any required changes in the process—this tends not to be very much work, and has proved to be pretty quick and easy. At some point, a new release then needs to be cut and published; I guess that could be automated, though currently it isn't.

There's an existing such automated PR that's open but that I haven't yet got round to merging (#22), and I see that the workflow has been failing recently for some reason (maybe as a result of me leaving that PR open for too long: it relies upon caches that GitHub periodically expires).

Part of the reason that I haven't got around to merging that open PR or fixing the broken workflow is that I'm minded to make the changes that I discussed in #15 and which are on the contextual_cmp branch. However that branch currently doesn't have the git history, for which I've been working on a tool to help bring it in (and keep it sync'd) in a similar fashion to the current workflow but that would track the history through renames and copies, which the current tool does not.

A case can certainly be made that this repo should be taken over by rust-lang and used as the implementation underlying the std library in the same manner as hashbrown underlies the std library's HashMap. This could happen today without much problem, the main concern I think would be that it's not worth the team's maintenance effort. That might change if this crate sees a lot of usage. I'd be delighted to see a push or IRLO discussion on that front if you think it's the right approach?

I agree that your third suggestion is too much maintenance effort, especially since there's already something semi-automated in place.