> 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. > > [1] https://github.com/mirage/ocaml-cohttp/issues/238 > <https://github.com/mirage/ocaml-cohttp/issues/238> > [2] https://github.com/mirage/mirage/issues/301#issuecomment-90729110 > <https://github.com/mirage/mirage/issues/301#issuecomment-90729110>_______________________________________________ > MirageOS-devel mailing list > [email protected] > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
