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

[Amir Chaudhry <amc79@xxxxxxxxx>]

> On 6 Jun 2015, at 18:46, Richard Mortier <richard.mortier@xxxxxxxxxxxx> wrote:
> 
>> 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.

I didn't mean to suggest that these should be 'known-good' -- I agree that it 
would become onerous.  Just the ability to 'revert' to some time would be 
useful. 

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

Ah, I see what you mean. We don't necessarily test for downstream breakages (on 
dependent libs). That's a good point but I think it's a wider one relating to 
CI that we should think about. 

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