Back in 2013, mirage-http was extracted out of cohttp into itâs own repository. Although Iâm ignorant of how the decision was made, I understand that there could have been good reasons for this a couple of years ago. Today, however, it seems like thereâs less good reasons for such a split. Now that opam supports multiple packages out of the same repo and since weâre planning on releasing cohttp backends as their own packages [1], maybe it makes sense to treat mirage-http the same way?
Yes, we wanted to have a separate opam package for mirage-http, and at the time it was the only possible option (now, with <package>.opam, it would be possible to keep the code in the same repository).
However I think having the code outside in this case is better (even though not necessary easier) as we also need to synchronise the release of mirage-http with the mirage tool (which generates some code using mirage-http). So I think, having a separate release schedule for cohttp and mirage-cohttp (and thus separate repositories and maintainers) makes sense in that case even if it can cause some trouble to the maintainers.
