Re: [MirageOS-devel] Updating TROVE or maintaining a remote

[David Sheets <sheets@xxxxxxxxxxxx>]

On Fri, Aug 7, 2015 at 12:03 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> Hi all,
>
> Christophe Troestler and Amir have been working on some infrastructure to 
> make it easier to manage the growing number of distributed MirageOS 
> repositories.  These not only include the core libraries, but also the 
> essential community-driven ones that aren't directly MirageOS-related but are 
> still core (like Lwt, or Daniel Buenzli's many libraries, or Rump kernel), 
> and then higher-level efforts like the TLS stack or the very new 
> CCM-encrypted block storage [1].
>
> So to drive these scripts, we need some metadata to get the list of 
> repositories.  We currently use the TROVE [2] file to keep track, but this is 
> always a little incomplete, and doesn't distinguish between the sorts of 
> repositories.
>
> My proposal is to maintain all of this metadata within OPAM.  We already have 
> a "org:mirage" tag for many of the repositories, and it's possible to query 
> the "dev-repo" field to get the raw Git repository from there.  What is 
> missing is:
>
> - an OPAM remote that we maintain with all the unreleased packages (like the 
> ongoing ones for networking by Mindy, Jitsu by Magnus, autoscaling by 
> Mort/Masoud and so on).  This would only be used for metadata purposes.
>
> - Add additional tags to make it easier to filter these repositories.  I'm 
> open to what these should be, but something task-oriented is probably most 
> useful.  e.g. mirage-net2 for the reworked network stack, or mirage-irmin for 
> any storage related activities).
>
> - Build a dashboard view of issues, commits and so on from the aggregation of 
> this. Christophe is currently working on this, and I'm keen to add issue 
> tracking to make releases and standardised labelling of issues in GitHub 
> easier.  Once David Sheets finishes up the next iteration of Codoc, we can 
> also generate cross-referenced documentation.

This is a great idea and sounds basically like an enhanced opam2web
static site generator with extensive GitHub integration and broader
use as a tool beyond the bespoke application of the current project.
Something like this has been planned for a while but I'm happy to see
work progress on it.

I'd like to see an automatically generated list of 'lagging' packages
that only work with versions of dependencies that are not the newest.
This would probably need to be integrated into test results in order
to cross-check the explicit version constraints.

> Any thoughts on this?  Christophe is working on this infrastructure right 
> now, and we're keen to get something up and running in August.  I'm 
> particularly interested in missing workflow features that would make your 
> life easier as MirageOS developers and users.
>
> [1] https://github.com/ocaml/opam-repository/pull/4625
> [2] https://github.com/mirage/mirage-www/blob/master/TROVE
>
> thanks
> Anil
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

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