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.
Best,
Thomas
The reason why Iâm bringing this up now is that the current situation does have the disadvantage of confusing users and creating possibly unnecessary churn for maintainers [2]
Thanks,
Rudi.
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxxhttp://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
