Project Submission: fs2-compress

[lhns]

Project Name

fs2-compress

Project Short Description

Integrations for several compression algorithms with Fs2.

Project Type

In accordance with the Typelevel Charter, I am proposing the project be a:

• [ ] Organization Project
• [x] Affiliate Project

Additional Notes

As discussed in https://github.com/typelevel/cats/pull/4421

[rossabaker]

Awesome, thanks for the submission. Is there a code of conduct? Another recent affiliate project added one like this.

[rossabaker]

https://github.com/orgs/typelevel/teams/steering: please vote with reaction on the issue. 👍 for yes, 👎 for no, 👀 for abstain.

I'll leave it open three business days (through Wednesday, April 19) and until quorum is reached.

[ChristopherDavenport]

I have a question, as fs2 currently has compression and uncompression(https://github.com/typelevel/fs2/tree/main/core/shared/src/main/scala/fs2/compression). Why a separate library rather than upstreaming these?

I am the last one to judge doing that, being guilty of it innumerable times, but I'm curious.

[lhns]

Awesome, thanks for the submission. Is there a code of conduct? Another recent affiliate project added one like this.

Currently there is not but I can add one if needed.

I have a question, as fs2 currently has compression and uncompression(https://github.com/typelevel/fs2/tree/main/core/shared/src/main/scala/fs2/compression). Why a separate library rather than upstreaming these?

I am the last one to judge doing that, being guilty of it innumerable times, but I'm curious.

The library is mostly just a wrapper around other jvm libraries so not all modules can be cross-compiled for js or native. I don't know if it is desirable to have these wrappers directly in fs2.

[rossabaker]

Yeah, if you could add a Code of Conduct, that would be excellent. It's rare to have an issue that requires invoking it on most projects, but it sends a good and welcoming signal to have one in place. A compatible CoC (and an appropriate open license, which you have) are two things the charter calls for.

If this were directly in FS2, the release cycle of FS2 (and everything downstream) would be tied to the release cycles of all libraries you wrap. I think the standalone project is wise. Arguably, these modules should have their own release cycles, or else a breaking change to brotli (for example) would trigger a major release for all fs2-compress consumers. But splitting it further would be a lot of administrative overhead for several tiny modules, and you can always address that problem if and when it becomes real.

[lhns]

I have added a Code of Conduct to the repository. I had the same thoughts about module versioning. For now they will all be on the same release cycle but this might change in the future.

[rossabaker]

@typelevel/steering This just needs one more response to make it official...

[rossabaker]

Approved. :tada: Welcome! Next steps, namely adding to the website, are tracked in #99.