Re: [MirageOS-devel] MirageOS fortnightly call - Wednesday 1st at 4pm BST

[Richard Mortier <richard.mortier@xxxxxxxxxxxx>]

On 6 July 2015 at 17:06, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> The call notes are below, and should be on the website in 30 minutes or so.
> I also took the opportunity to write up Dave Scott's email notes about
> how to use coveralls.io -- I'll be trying them shortly myself for some of
> the webstack.
...
> #### Mirage 2.5 release
>
...
> - Do not release on a Friday afternoon and then go to the pub (or in the case 
> of
>   ThomasG, a wedding)

(Though it is traditional SRG behaviour to do just that, preferably
going on holiday for several weeks, back at least to Nemesis days ;)

...
> *ThomasG:* Mirage is a set of libraries that work together and a frontend 
> tool that glues
> them together.  Its fine to release libraries as a batch since we have OPAM, 
> but what we
> didnt manage well is evolving the API of the Mirage DSL itself which glues it 
> all together
> (Anil: this is referring to the `config.ml` API).
> *Mort:* the Mirage DSL eis an implicit collation of a bunch of library 
> versions and it is
> hard to track since its not captured in OPAM.
> *ThomasG:* we can fix this by adding conflicts in the OPAM metadata.

DIdn't we agree that adding piles of upper-bound constraints wasn't
desirable though?

> *ThomasL:* a number of Mirage packages have gone upstream into the OPAM 
> package
> repository and their unit tests fails. More testing on OPAM import is needed 
> to
> prevent dependent packages from breaking their unit tests due to an import of 
> a
> dependency.  *DavidS:* we only test the package version we are importing and 
> so
> we only test for one solution. Further changes will break upstream. We dont do
> reverse dependencies for OPAM dependency tests.
> *Anil*: The OPAM maintainers (several of whom are on this call) are aware of 
> the
> issue and are working on improving testing reverse dependencies on new 
> package import.
>
> *Mort/DavidS*: the Mirage libraries should use the 
> [ocaml-travis-ci-skeleton](https://github.com/ocaml/ocaml-travisci-skeleton) 
> so that they take advantage of the improvements in reverse depenedency 
> testing.
> *Mort*: we need to figure out how to get around the Travis 50 minute limit.

Specifically -- I was proposing that CI testing should be CI testing
(not simply "does it still build" testing), by building some of the
depends-on packages against the newly built library in question.
DavidS noted that REVDEPS (IIRC) is already a supported variable for
the ocaml-travisci-skeleton scripts and needn't be set to "*" as it
often currently is, but could be set to a few chosen reverse
dependencies to at least try and avoid (or detect anyway) major
downstream breakage.

Ie., I think that with a few minor additions to relevant .travis.yml
files, this bit of the situation can probably be improved immediately.
(I have the impression that many Mirage libraries already use the
skeleton scripts.)

-- 
Richard Mortier
richard.mortier@xxxxxxxxxxxx

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel