On 6 June 2015 at 18:00, Amir Chaudhry <[email protected]> wrote: > >> On 6 Jun 2015, at 14:13, Richard Mortier <[email protected]> >> wrote: >> >> On 4 June 2015 at 23:02, Thomas Gazagnaire <[email protected]> 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 [email protected] _______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
