In #375 (comment) 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, #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.
In #375 (comment) 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, #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_inetc.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_blockingIn 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.