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

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

> On 7 Aug 2015, at 12:03, 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:

I think this is a good idea. I always forget to modify TROVE, but itâs hard to 
forget the tags in the opam metadata when youâre in the middle of releasing and 
theyâre right in front of you.

> - 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.

This also sounds good. Over in the xapi-project we use an opam-repo-dev for all 
of our half-baked stuff and hook it into travis builds via the EXTRA_REMOTES 
environment variable. Seems to work quite well. The only thing is we sometimes 
forget to do the formal releases or are lazy and just leave things in the 
unreleased repo.

> 
> - 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.

A dashboard view that showed me how many of the repos Iâm looking after have 
unreleased commits in â and would let me drill down into the detail -- would be 
very useful.

Cheers,
Dave

> 
> 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