[opam-devel] [ocaml-infra] Automatically synching GitHub pulls to OPAM

[Anil Madhavapeddy]

On 7 Feb 2014, at 17:02, Jeremy Yallop <yallop at gmail.com> wrote:

> On 7 February 2014 16:46, Amir Chaudhry <amc79 at cam.ac.uk> wrote:
>> Does seem very useful and an easy way for package maintainers to see how proposed patches might affect them..
>> 
>> Naiive question (since I haven't tried this myself): Does the switch grab the latest trunk version and apply the patch or does it take 4.01.0 and apply it?  I notice that the PRs are all for trunk.
> 
> The compiler version is a command-line option:
> 
>   https://github.com/avsm/opam-sync-github-prs/blob/88a403eb8/generate.ml#L63

Right. Also note that you can refresh against the branch by running

$ opam switch reinstall 4.02.0dev+pr7

> 
> I wonder whether it'd be more reliable to use the source branch in the
> pull request as the 'src' for the switch.  For example, for #6,
> instead of generating
> 
>    src: https://github.com/ocaml/ocaml/archive/4.0.2.tar.gz
>    patches: https://github.com/ocaml/ocaml/pull/6.diff
> 
> we might simply have
> 
>   src: https://github.com/hnrgrgr/ocaml/archive/type_constraint_warning.tar.gz

I did consider this, but there is a difference between the two.  With
the "fetch base branch + apply patch diff" approach, every installation
is rebasing against the current base branch (usually trunk).  With the
alternative you propose, it would be against the revision that the pull
request was opened against (as I believe that GitHub only includes the
fake merge commit upon merging, not upon fetching the archives).

Overall, I prefer the rebasing approach since it makes it obvious when
a PR fails against the latest branch it's intended for, and we don't want
to encourage un-rebased patches against trunk that don't merge anyway.

It could easily be made an option, but I'd prefer that we just pick one
approach for the regular cron-driven merges to the stable OPAM repo.

-anil