Unified issue tracker between HTTPX and HTTPCore #1528
Replies: 3 comments
-
At the moment it feels like the right thing, yup. I'm not even against us thinking about if we should just be maintaining it all as a single package, but with a really clearly defined interface split at the transport API level.
|
Beta Was this translation helpful? Give feedback.
-
@tomchristie Dunno about the package split, I think it really nicely enforces the interface split (eg by making it harder to sneak network features in HTTPX and vice versa). But that's something we can discuss separately if we feel it. :-) So as for unifying issue trackers on this HTTPX repo, a clear yes it seems? Curious what the migration process would look like. I guess something like this?
|
Beta Was this translation helpful? Give feedback.
-
I transfered #1245 here and applied the |
Beta Was this translation helpful? Give feedback.
-
HTTPX and HTTPCore are companion projects - one does high-level client features, the other low-level HTTP networking.
Currently we have two separate bug trackers, one on each repo. At the beginning this seemed natural, since there's a clear responsibility split between the two projects, so surely issues can be split based on this frontier as well.
However in practice it induces a bit of pain in terms of contributor and maintainer experience. Folks tend to open issues on HTTPX that may belong to HTTPCore, and transfering them means that those issues aren't directly visible by people that visit the HTTPX repo (because, well, where else would they go to?).
@tomchristie raised the idea of using a single issue tracker (the one on HTTPX), and I think it might make sense.
We can add an
httpcore
label for any issue that actually relates to HTTPCore rather than HTTPX. Everything will be visible by everyone in one place. Since we can close issues from PRs across repos this won't hinder the contributor experience on the HTTPCore side either.Any further thoughts?
Beta Was this translation helpful? Give feedback.
All reactions