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

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

Thanks for the views, everyone! I've started hacking on the tools and recording 
notes in:
https://github.com/mirage/mirage-www/wiki/OPAM-Aggregation

I'll update on the Mirage call on Wednesday with how it all looks.  In the 
meanwhile,
if you have opinions on workflows you'd like, please continue to update them 
here.

To answer some specific points:


> On 8 Aug 2015, at 12:53, Mindy <mindy@xxxxxxxxxxxxxxxxxxx> wrote:
> 
> On 08/07/2015 06:24 PM, Dave Scott wrote:
>>> - 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.
> I'm not sure what Anil means by "only be used for metadata purposes" - does 
> this mean there would be no guarantee that the packages in the remote are 
> internally consistent, i.e. setting it as a remote wouldn't be expected to 
> work?  (I have no objection to that, necessarily, but I want to be sure I 
> understand what's proposed.)

This is a good point -- one issue with remotes right now is that they are 
global across switches, and so "pollute" everything that you are working on if 
they expose broken packages.

I think this is a pretty big design flaw in OPAM, and that remotes ought to be 
switch-local by default.  If this were the case, then it wouldn't matter if a 
particular switch were broken occasionally.

With them being global however, we do have to keep them vaguely working.  So I 
was thinking that we could have a "super bleeding edge" remote with working 
packages that was never intended to be used as a development remote, only as an 
automated-scripting remote.  After that, another remote would be what the 
current opam-repo-dev contains.

>>> 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.
> This may be out of scope, but I'm not in the Mirage organization so I've had 
> to watch a lot of repositories by hand (and I'm certainly still missing 
> some); it would be nice to be able to watch them all automatically.  A common 
> dashboard would probably replace most of my need for this (probably modulo 
> e-mail notifications, which I do find useful).

Definitely not out of scope.  Similarly, I have a tough time seeing activity in 
mirleft/* for the TLS repositories sometimes.  I've recorded this in the wiki 
page as well.

Regarding the changelog discussion, I'll take a closer look at what a detailed 
changelog will look like.  That'll come after the first round of HTML changes 
though.

-a


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