[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] Random thought for an OPAM feature
> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |