[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] What was the reasoning for splitting out mirage-http?

On 9 Apr 2015, at 00:52, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:

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.

I agree with this.  It does however highlight the need for a reverse-dependency checking tool to figure out whether or not a pull request dramatically breaks something or not.  I'll work on this with David Sheets (who has done much of the GitHub work necessary), and it's a good excuse to use Irmin as well.

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.