Re: [MirageOS-devel] Random thought for an OPAM feature

[Amir Chaudhry <amc79@xxxxxxxxx>]

> On 6 Jun 2015, at 14:13, Richard Mortier <richard.mortier@xxxxxxxxxxxx> wrote:
> 
> On 4 June 2015 at 23:02, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
>> The goal is to keep the master branches of mirage-www and mirage-skeleton 
>> always work fine with base opam, and have a mirage-dev branch on these repo 
>> when we prepare a bulk release in mirage/mirage-dev.
>> 
> 
> It's a start, and probably something useful to have. My concern is
> that we won't be rigorous in keeping the master/dev branches aligned
> with the release/dev OPAM repos, and the same confusion will result.
> Having the capability with OPAM that I suggested might provide the
> "end user" with a simple way to reconcile temporary breakageâ

I see this from two perspectives.  One is that of a MirageOS developer and the 
other is of a MirageOS user (I hope that distinction makes sense).

For the developer, what Mortâs suggested makes a lot of sense.  Being able to 
get âThe state of MirageOSâ for a given date seems like it would be pretty 
useful (as would being able to share that list with people).  

For an end user, I donât think we should ever have to say âpin to a date with 
known-good package-setsâ.  Itâs an extra thing to think of (and therefore an 
extra thing to get wrong or have to ask about in bug reports).  Itâs reasonable 
for a user to expect that things are in sync with mainstream opam and we should 
keep things that way.  If a user experiences breakage with that set, we should 
treat it as a bug and remedy it accordingly.

In terms of keeping things aligned, I think we just have to ensure a divide 
between 'pushes to devâ branches and âreleases to masterâ branches.  I think 
weâve done ok with mirage-dev so far so this just seems like a matter of 
pushing to different branches instead of master.  I believe the only additional 
steps would then be merging mirage-www and mirage-skeleton dev branches into 
master upon release (assuming no conflicts).  That doesnât seem particularly 
onerous â unless, Iâm missing something?

Amir



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