Maintenance

[jplatte]

It looks like this crate is hardly maintained. Many of the open issues, most of them many months old, haven't received any comments, and four PRs (the latest one from Nov 2020) are also sitting there without any feedback.

@akubera Do you intend to more actively maintain this crate soon? If not, would you be open to

• add collaborators with write access to the repo or transfer ownership (possibly to an organization) and
• add one or more additional owners to the crates.io package?

Since this crate is a dependency (though optional) of both diesel and SQLx, it probably won't be that hard to find people willing to help with maintenance.

[mreschke]

Agree. Need to let someone else help you with this repo so we can have a stable BigDecimal in rust.

[akubera]

I'm sorry I haven't been paying attention to this project. The efficiency is quite terrible and last December I had actually started reimplementing everything using Vec's directly, instead of the relatively opaque BigInts, and then slowed down on working on that all together :-(.

I figured the reimplementation (which kind of has to happen, if we want good performance) would be the place to implement the useful things like context which would answer many of the issues people have, but obviously it's taking too long.

I'll go back to focusing on maintaining the version as-is, and I'll check into GitHub more often.

Again, sorry if this has caused any inconvenience.

Also, I'd like to everyone interested to discuss implementation details on the project gitter. Though, since nobody is using it, I wonder if there's a more popular chat solution that rustaceans would prefer?

[mreschke]

I would say BigDecimal is a popular and valuable library in the Rust ecosystem. I would be proud of that and see it as worth maintaining...already have good traction, keep it going. Deciding to re-write a project is a tough decision I know, and it takes a lot of time and effort. I do suggest chipping away at a new version if performance is really that bad, but in the mean time, put a bit of effort into the old code. I would suggest going through all these issues and fixing things up to make a good stable 1.0 of this older slower code. It's also nice that people have already fixed your code with PR's waiting for you to merge. Once 1.0 is stable I would casually work on a "next" branch for 2.0 re-write / performance booster. 1.0 could be feature frozen forever, although real bugs should always be fixed, even in frozen releases, they are important to give a bit of energy too.

Not sure about gitter or best place, but for me personally, I like all things to be on one place, right here on github. Easier for other people too. Github added a new "discussions" feature you can enable in the repo settings. Good for separating actual issues vs discussions like these.