> The OPAM tool indeed supports this model, but the automation infrastructure > isn't fully written and deployed yet. There are various tools in-flight that > do portions of this, but none exist that poll the --dev repository (e.g. for > a new GitHub release) and autocreate a PR.
yes, that's a very good idea! (and not difficult to do actually) > I think that's an interesting idea, as instead of the repository maintainer > pushing a release and OPAM package, we could take the burden off the creator > and poll for releases on the upstream GitHub repositories instead. > > One advantage of this "pull" model is that it ensures that the upstream > `opam` metadata is sane, since that would form the basis for the PR. Right > now they can diverge due to manual intervention. > > Anil > >> On 22 Feb 2016, at 22:14, Cheng Lou <chenglo...@gmail.com >> <mailto:chenglo...@gmail.com>> wrote: >> >> Sorry for hijacking the discussion. I'm new to OPAM, but is there a reason >> why PRs for package upgrades can't be managed automatically? E.g. asking for >> a git URL and either periodically check for new release tags, or check on >> the fly when installing a library. >> >> On Wednesday, February 17, 2016 at 7:27:49 AM UTC-5, Fabrice Le Fessant >> wrote: >> Hi, >> >> If there is some need to help managing PRs to the opam-repository, >> Grégoire Henry (OCamlPro-Henry on Github) and myself (lefessan on Github) >> are volunteers to spend some time doing it. >> >> Best regards, >> --Fabrice >> >> _______________________________________________ >> opam-devel mailing list >> opam-devel@lists.ocaml.org <mailto:opam-devel@lists.ocaml.org> >> http://lists.ocaml.org/listinfo/opam-devel > > _______________________________________________ > opam-devel mailing list > opam-devel@lists.ocaml.org > http://lists.ocaml.org/listinfo/opam-devel
_______________________________________________ opam-devel mailing list opam-devel@lists.ocaml.org http://lists.ocaml.org/listinfo/opam-devel
