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

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

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

MirageOS-devel mailing list



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