On 9 Apr 2015, at 00:52, Thomas Gazagnaire <[email protected]> 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.
-anil
_______________________________________________
MirageOS-devel mailing list
[email protected]
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
