This is incredible! Now let's get them all compiling and running unit tests on Travis! Yotam On Tue, Mar 25, 2014 at 12:40 PM, Anil Madhavapeddy wrote: > As a followup to this, I've written a script that syncs all the > open pull requests against the compiler as OPAM compiler switches. > This is now running live on the central OPAM respository. > > For instance, if you now `opam update` and look at your switches: > > $ opam switch --all > -- -- 4.02.0dev+pr10 Add String.{split,rsplit} > -- -- 4.02.0dev+pr13 Add String.{cut,rcut}. > -- -- 4.02.0dev+pr14 Add absolute directory names to > bytecode format for ocamldebug to use > -- -- 4.02.0dev+pr15 replace String.blit by > String.unsafe_blit > -- -- 4.02.0dev+pr17 Cmm arithmetic optimisations > -- -- 4.02.0dev+pr18 Patch for issue 5584 > -- -- 4.02.0dev+pr2 Parse -.x**2. (unary -.) as > -.(x**2.). Fix PR#3414 > -- -- 4.02.0dev+pr20 OCamlbuild: Fix the check of > ocamlfind > -- -- 4.02.0dev+pr3 Extend record punning to allow > destructuring. > -- -- 4.02.0dev+pr4 Fix for PR#4832 (Filling bigarrays > may block out runtime) > -- -- 4.02.0dev+pr6 Warn user when a type variable in a > type constraint has been instantiated. > -- -- 4.02.0dev+pr7 Extend ocamllex with actions before > refilling > -- -- 4.02.0dev+pr8 Adds a .gitignore to ignore all > generated files during `make world.opt' > -- -- 4.02.0dev+pr9 FreeBSD 10 uses clang by default, > with gcc not available by default > -- -- 4.02.0dev+trunk latest trunk snapshot > > Each switch corresponds to the current development trunk, with the > diff in the PR applied. If the patch is sane, you can proceed to > install OPAM packages in the experimental tree as usual without > affecting your day-to-day compiler switch. > > Hope this is useful! More details at: > http://anil.recoil.org/2014/03/25/ocaml-github-and-opam.html > > It's set to run daily at the moment, and switches will be deleted once > the corresponding pull request is closed. > > cheers, > Anil > > On 30 Jan 2014, at 11:34, Gabriel Scherer > wrote: > > > TL;DR: During the six next months, we will follow pull requests (PR) > > posted on the github mirror of the OCaml distribution, as an > > alternative to the mantis bugtracker. This experiment hopes to attract > > more people to participate in the extremely helpful and surprisingly > > rewarding activity of patch reviews. > > > > > > Dear OCaml community, > > > > I think we need more people ready to review patches proposed for > > inclusion in the OCaml compiler/distribution; lack of reviews is > > currently one of the bottleneck in the development process -- among > > others, such as the sheer difficulty to reach consensus on any change > > to the language itself. Doing patch reviews is helpful, extremely > > interesting, and an excellent way to get to know more about small > > parts of the compiler. > > > > There was a resurgence of discussions on caml-list (Yotam Barnoy's > > [moving to github] and Adrien Nader's thoughtful proposal of > > a [mailing-list for patch review]). Amir Chaudhry launched a poll to > > record decreasing order of preference, and the [results] are > > clear-cut: people hate Mantis' guts, and would rather use anything > > else. > > > > [moving to github]: http://alan.petitepomme.net/cwn/2013.12.24.html#5 > > [mailing-list for patch review]: > > https://sympa.inria.fr/sympa/arc/caml-list/2014-01/msg00055.html > > [results]: > https://docs.google.com/forms/d/1QWhqJRv1yPvdi6E3AiqbvUwlqGorV_Wbk7h_JYuDUiQ/viewanalytics > > > > I declare open the following experiment: for six months, starting > > today upto late July, patches proposed for the OCaml distribution may > > be submitted as a pull request (PR) on the [main github mirror], and > > we warmly encourage anyone to review the proposed patches, and make > > any comments they feel can help. Anything that can help improve the > > contribution, or discuss potential issues (backward compatibility, > > future-proofiness of the change, alternative designs...) will speed up > > the time between a patch proposal and a clear decision to integrate it > > or not. > > > > [main github mirror]: https://github.com/ocaml/ocaml/ > > > > In six months, we will reconsider, the default choice being to stop > > using github and revert to a mantis-only workflow. In the meantime, > > I will mirror the github PRs on the mantis side, so that contributors > > that do not wish to use the github interface can continue working as > > before. Patches and reviews are of course still welcome on mantis. > > > > Note that github will *not* be used for issue tracking, only for patch > > reviews. If you want to submit a patch against a bug discussed in > > Mantis, or want to re-submit a patch already in Mantis (in the wild > > hope of more eyeballs), feel free to send a github PR and link to it > > from the bugtracker. Finally, the github mirror remains *read-only*: > > if patches are accepted, the PR will be closed but will be committed > > to the SVN first, and synced in git as usual. > > > > We're just trying things to see if it works better. I hope it does. In > > any case, thanks in advance for your participation -- whichever tool > > you use. Happy hacking! > > > > . > > > > PS: If you want to get notified for all Pull Requests sent, you > > (need a github account and) can click on the "Watch" button in the top > > right of http://github.com/ocaml/ocaml to register for > > notifications. In the [notification settings] page of your account, > > you can set up notifications to get send by email and/or to the > > (mostly useless) github notification web interface. > > > > [notification settings](https://github.com/settings/notifications) > > _______________________________________________ > > Platform mailing list > > Platform@lists.ocaml.org > > http://lists.ocaml.org/listinfo/platform > > > > _______________________________________________ > Platform mailing list > Platform@lists.ocaml.org > http://lists.ocaml.org/listinfo/platform >