search

alexcrichton / tar-rs

Tar file reading/writing for Rust
https://docs.rs/tar
Apache License 2.0
624 stars 184 forks source link

maintenance consensus issue tracker #379

Open cgwalters opened 5 days ago

cgwalters commented 5 days ago

In https://github.com/alexcrichton/tar-rs/pull/375#issuecomment-2372645098 Alex is currently planning to invite me (done) and @xzfc as maintainers.

Let's try to get some rough consensus here for our goals for this crate and set expectations for people.

For me things are pretty easy to say: I work on OCI containers and tar is pretty central there. The ecosystem is heavily Go oriented but I am also trying to increase the use of Rust there, somewhat successfully. (For example, https://github.com/microsoft/rpmoci is a relatively new project I came across that uses this crate along with another I maintain).

From my PoV the crate mostly works as is, and I don't need substantial new features, just occasional API conveniences.

So specifically for example, https://github.com/alexcrichton/tar-rs/pull/355 is a change that's beyond my review/maintenance bandwidth and I am inclined to reject.

In fact more generally, something on my mind is to try to split off some of the API types and helper functions into something like a "tar-core" that would operate more sans-io style. For multiple reasons my consuming code ends up doing more custom and sophisticated things than just mapping a tar directly to/from a filesystem, so I don't really use the high level APIs here like unpack_in etc. Also a sans-io crate would allow sharing code with https://docs.rs/async-tar/latest/async_tar/ - and today I actually do tar processing in a tokio::task::spawn_blocking

In other words to sum things up: I want a crate for tar that has a solid collaborative maintenance but to be generally conservative about features we add and has a strong code review/testing and rough consensus approach. In fact I would go so far as to say that merging a big nontrivial PR here would require a review from two maintainers (exactly like 365 above).

@alexcrichton is that all OK with you?

If @xzfc accepts being a maintainer too I'd like them to write up something similar here and then we can add it to the README.md and set clear expectations for future contributors.

alexcrichton commented 4 days ago

Sounds reasonable to me 👍. Although I wouldn't necesarily reject PRs like #355 outright, but more leave a comment saying "sorry but at this time the review bandwidth isn't here for this" or similar.

NobodyXu commented 3 days ago

Also a sans-io crate would allow sharing code with https://docs.rs/async-tar/latest/async_tar/ - and today I actually do tar processing in a tokio::task::spawn_blocking

I would really want to see that happen.

cargo-binstall currently has to use both a fork of tar and async-tar, because async-tar does not support parsing tarball with sparse entries.

We also have a fork of tar because the sparse entries wasn't merged.

Having a sans-io crate would enable us to use one tar implementation within cargo-binstall, and remove the spawn_blocking/block_in_place for better ergonomic.