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

[Richard Mortier <richard.mortier@xxxxxxxxxxxx>]

On 6 June 2015 at 18:00, Amir Chaudhry <amc79@xxxxxxxxx> wrote:
>
>> 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.
>

Yes; but I was trying to avoid the need for us to publish (and curate)
a list of known-good revisions of all the packages that might be used.
Given the number of libraries involved and the number of possible
combinations that may arise, this feels like it could get rather
onerous.

But as a Mirage user (not currently dramatically different from Mirage
developer, and almost certainly someone who has a passing acquaintance
with use of OPAM, command line tools etc), I can generally keep my own
development environment working fairly stably. Except when something
auto-updates at the wrong time, in which case being able to "revert"
to a known good date might be enough.

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

This is fine, and I think we do this ok, for dev vs release generally.
The problem seems to be some way to manage things when there are so
many inter-dependent libraries that it's not really feasible for (eg)
CI testing to actually test all dependencies on a given library -- at
the moment, all we really test is that committed code builds, not that
dependencies on that code still build.


-- 
Richard Mortier
richard.mortier@xxxxxxxxxxxx

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