Do you need help to maintain this project?

[guilload]

Hello,

Do you need help to maintain this crate? I noticed little activity regarding reviews, merged PRs, and releases over the last few months. I'm happy to give you a hand.

[robjtede]

Came here to ask this, too, after reviewing my open pull requests. We use this crate in actix-multipart. Happy to take on some responsibility for maintenance @hyunsik

[MrCroxx]

Hi folks. I've forked this repo to https://github.com/foyer-rs/bytesize and made some differences.

Differences from the original bytesize

• Use SI format by default with Display.
• Use "KiB" for SI unit.

Considering the changes, the version of foyer-bytesize crate starts from "2" to differ from the original bytesize crate.

FYI: https://github.com/foyer-rs/bytesize#differences-from-the-original-bytesize

If you need the features, you can use foyer-bytesize as:

bytesize = { package = "foyer-bytesize", version = "2", features = ["serde"]}

And I'm happy to either help to maintain the repo, or contribute back to the upstream if @hyunsik is still maintaining this repo.

[hyunsik]

Hi,

I'm very sorry about no activities for a while. I'm spending all of my energy to my job. So, I cannot afford to contribute this project. I would be really happy if someone takes the responsibility for maintenance.

@guilload @robjtede @MrCroxx are you guys interested?

[MrCroxx]

Hi, @hyunsik . Thank you for maintaining the lib for a long time. It is really hard to maintain an open-source project for years.

I'm happy to take the responsibility. However, I've already forked one copy to https://github.com/foyer-rs/bytesize and made some refactors (FYi https://github.com/foyer-rs/bytesize#differences-from-the-original-bytesize) and released a new major version. The changes are for my own convenience, I'm not sure if we can make a consensus on the changes. Would you like to check if the changes are okay? If they are fine, I'm happy to contribute to back to this repo and maintain it.

[robjtede]

Hey @hyunsik yes I'm also happy to take up maintenance of this crate.

[hyunsik]

Hi,

You guys have been contributed a lot to many Rust projects. I've invited @MrCroxx and @robjtede to the collaborators of this project. I'm really happy to work you guys in this project.

Now, we are three. So, we may need some contribution rules. Here, my suggestion about the maintenance of this project. I welcome to any feedback from you guys. Please feel free to leave your comments.

• Merging a PR and a release requires at least one approval from one of @MrCroxx @robjtede @hyunsik
  • Without approval, you guys still can merge a simple typo and trivial change which don't affect APIs and APIs behaviors
  • The above rule may be ambiguous. Let's see how it works and improve the contribution rules.
• If there is an objection about code modification or project roadmap, let's discuss and follow the majority.

@MrCroxx Your change basically look good to me. If you are Ok, you can make your changes to PR and let's merge through the above process.

[robjtede]

For my own projects, I like to enforce a changelog, whether contributed or self-written after the fact. Either way, I think it's important to keep track of alterations to public items. I also find it's easier to do in-tree than having to trail back through commits when a release is being prepared.

[MrCroxx]

Hi @hyunsik , thanks for your trust. Let's continue this cool project.

Your change basically look good to me. If you are Ok, you can make your changes to PR and let's merge through the above process.

Sure. I'll send a PR for it.

@robjtede For my own projects, I like to enforce a changelog, whether contributed or self-written after the fact. Either way, I think it's important to keep track of alterations to public items. I also find it's easier to do in-tree than having to trail back through commits when a release is being prepared.

LGTM. Let's work on it. Let's start with v2.

[MrCroxx]

PR sent as a draft. Gonna work on the readme and changelog these days. #50

[MrCroxx]

BTW, could you please set the repo only allow squash merge? IMO, it will make the commit log clearer.

[hyunsik]

For my own projects, I like to enforce a changelog, whether contributed or self-written after the fact. Either way, I think it's important to keep track of alterations to public items. I also find it's easier to do in-tree than having to trail back through commits when a release is being prepared.

I totally agree with that. Let's do that.

BTW, could you please set the repo only allow squash merge? IMO, it will make the commit log clearer.

I agree with that. Sure, let me set up for only squash merge.

[MrCroxx]

Seems we can close the issue now.