Re-homing + new maintainers

[woodruffw]

Given the lack of maintainer activity and growing issues (xrefs below), I think it might be time to consider a (soft) fork of this project.

I'm willing to temporarily maintain such a fork, at least until the maintainer becomes available again (or expresses a disinterest in continuing to maintain, at which point it'll become a hard fork). My maintenance interest is primarily as a downstream user of CacheControl, namely in pypa/pip-audit.

I'm opening this issue to gauge interest/appetite for such a fork.

xrefs:

• cachecontrol is incompatible with Requests 2.30.0 #292
• serialize.py function fails with HTTPResonse has no attribute "strict" #293
• urllib3 2.0: Double reading causes IncompleteRead error #295
• test_not_modified_releases_connection fails with requests 2.29.0 #297
• 0.12.12: pytest is failing in tests/test_etag.py::TestReleaseConnection::test_not_modified_releases_connection unit #298
• 0.12.12: tests/ content is installed #299

[frostming]

I already created one at https://github.com/frostming/cacheyou and already uploaded to the PyPI. If you are interested I can add you to the collaborators. The workflow is also changed a bit.

[woodruffw]

Oh, fantastic!

Yes, I'd be happy to collaborate on it -- I started some changes on https://github.com/woodruffw-forks/cachecontrol/tree/modernize (including cherry-picking your double-read fix), but it looks like you've already got most of the same ones covered 🙂

I haven't used PDM before, but I'm happy to try.

[frostming]

Good, I've sent the invitation and I will complete the dev guide shortly.

[adiroiban]

Rather than moving to a fork that is maintained again by a single person, I guess it's much better to find an umbrella organization to host the package.

I remember that @ionrock was active in the #294 PR.

I think that instead of links to issues, is best to provide links to PRs that are in great shape and ready to merge, but not merged because @ionrock didn't had time to approve them.

In the case of #294 the PR description is fix: compatibility with urllib3 2.0 but it contains unrelated formatting changes and unrelated import reordering changes.

[ionrock]

Hey folks, I'd be happy to find an org to host and maintain this package. I don't have the time to invest and would feel most comfortable with an org taking it on. Feel free to provide any options in this ticket, and if you're interested in helping to make the transition. Thanks all!

[woodruffw]

Thank you @ionrock!

My preference for organizational control as well -- it looks like me and @frostming are PyPA members, but (IMO) the PyPA is probably the wrong venue for this kind of package.

Some other ideas:

• Could we have this homed under the "main" PSF org, similar to requests? An argument for this is that CacheControl is an integral part of the requests ecosystem.

• Are there community-based orgs that would be a right fit for this? The two that I'm aware of are jazzband and pallets, but there may be others and I'm not sure either of these is right.

[adiroiban]

My suggestion is to try to move this into https://github.com/requests/

I think that this library is all about the requests project.

I see that the request project itself is hosted by the Python Software Foundation github org.

We have https://github.com/requests/toolbelt and I think that the https://github.com/requests GitHub Org can be used for the Requests ecosystem tools.

[Secrus]

Moving the repo to an org won't automatically solve the problem of a lack of maintainers. I'd say that the project could be left as it is, you just need people interested in helping with maintenance.

[woodruffw]

I think neither of those is salient in this case: the current maintainer has expressed a willingness to re-home it under an org, and there are at least two people in this thread who are willing to maintain it (myself and @frostming).

[ewdurbin]

PSF will happily accept a transfer and manage access!

[woodruffw]

PSF will happily accept a transfer and manage access!

Awesome! I think @ionrock will have to coordinate it if it's done as a transfer; from there, myself or @frostming (or anyone else who'd like to offer maintenance) can be added.

[Secrus]

I think neither of those is salient in this case: the current maintainer has expressed a willingness to re-home it under an org, and there are at least two people in this thread who are willing to maintain it (myself and @frostming).

Yeah, I just meant that is about people, not the org the repo is under.

PSF will happily accept a transfer and manage access!

Awesome! I think @ionrock will have to coordinate it if it's done as a transfer; from there, myself or @frostming (or anyone else who'd like to offer maintenance) can be added.

I will be happy to help with maintenance as well.