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

[Amir Chaudhry <amc79@xxxxxxxxx>]

Hi folks,

Lots of useful things here and I think a quick clarification would help.

Christophe and I have been working on some initial tooling to get a better 
understanding of the progress of the OCaml community, based on the OPAM package 
repository. We've been using the MirageOS libraries as a test-case, since it's 
a fairly substantive set and we already had the MegaMirage git repo (and TROVE) 
to draw from. It's still a work in progress and is only looking at Git repos 
themselves for the moment (not GitHub) -- it will take additional work and 
contributions before it's ready to use as described in this thread (which I 
assume is what Anil is hacking on). I just want to be clear about expectations 
:)

Aside from that, some comments on the points made so far:

- OPAM tags -
It would be good to get more usage of tags in the OPAM metadata and the idea is 
to stop using MegaMirage/TROVE in favour of tags.  I've no issue with the 
suggestions so far but in the case of `mirage`, it would seem that *any* 
package that doesn't have an OS dependency could be part of the MirageOS 
ecosystem.  Packages that we do actually use, but do not maintain, can be 
revealed by looking at dependencies so is there a need to also tag them with 
`mirage`?

- OPAM remotes -
We've kind of had this discussion before [1] and I worry about having multiple 
remotes. I don't fully understand the proposal here but my concern is the same 
-- neatly summarised by Dave's example with the xapi-project remote (i.e. not 
always doing formal releases).  We want to insulate people from dev breakages 
(which is good), but we need to be diligent about proper releases (or people 
will just end up adding the remote anyway).

[1] https://mirage.io/wiki/weekly-2015-02-11

- Highlighting 'Lagging' packages -
This is a great point and would help to mitigate my concern above.

- Static site generation -
Ideally, anyone should be able to compose the pieces they need and easily 
create a simple site with the info they care about.  Mentioned already as 
having a view for 'gatekeepers' but I'm also interested in getting info on 
changes over time (e.g number of contributors, which repos people first engage 
with, etc).  These are useful for understanding how the community is developing 
(no pun intended).

Best wishes,
Amir

> On 10 Aug 2015, at 17:17, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> 
> 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


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