[ocaml-platform] Is it taking too long for OCaml software to become 4.03-compatible? Would release process changes help?

[Gabriel Scherer]

>
> I don't think that irresponsible people should be allowed to hold the
> whole eco-system back because of their behaviour.
>

If it seems to costly to fix a given package, we can always add an upper
bound and declare it done. My condition was that no package that pretends
to be installable should fail to build, not that all packages must be fixed.

Note that I would disapprove of "let's just automatically add an upper
bound on everything that fails at beta time" as a process to meet this
requirement. I would like this to be a human decision, to make sure that we
actually consider fixing them before making them uninstallable.

If specific software is found to be too fragile/unreliable to resist to
OCaml version changes (this arguably is the case of Batteries by design as
its testsuite breaks when the stdlib is extended and Batteries isn't to
match it up), we can decide to always add pessimistic upper bounds on its
packaged versions (Batteries, camlp5 do that). Then it's up to its
maintainers and users to relax the bounds after someone manually checked
that the package works correctly.


On Wed, Jun 29, 2016 at 4:21 PM, Daniel Bünzli <daniel.buenzli at erratique.ch>
wrote:

> Le mercredi, 29 juin 2016 à 20:39, Gabriel Scherer a écrit :
> > TL;DR:
> > 1. We need to have a "test:" field in OPAM metadata and get packages to
> use it.
>
> This already exists. But in a broken form in my opinion; see build-test:
> field. I hope OPAM v2 will propose something better (simply build: and
> test:), I talked with Louis about this.
>
> However note that most failures are build failures anyways — notably
> because a lot of the packages are affected, sometimes without knowing (rec
> deps) — by the pre-processing cancer that `ppx` and `camlp4` are.
>
> Also one other thing to note is that people stupidly have -warn-error
> activated in their tarballs. It should be communicated more effectively
> that this should absolutely not be done as it is difficult to check this by
> the OPAM repository maintainers.
>
> > 3. If such a weekly build is effective, the policy of "stay in beta as
> long as allegedly-installable OPAM packages fail to build on the new
> release" would be much easier to accept.
> I don't think that's reasonable. The responsability here is the one of the
> package developers — refrain from using hacks that are not able to pass a
> major version of the OCaml compiler — and the package maintainers (often
> the same person) who need to actually test and fix the packages they
> maintain once an OCaml beta is out; this should be especially true for
> people who distribute cancer inducing substances (but yes it's nice if we
> can be notified automatically). I don't think that irresponsible people
> should be allowed to hold the whole eco-system back because of their
> behaviour.
>
> FWIW AFAIK none of ~20 packages I maintain needed any kind of fixing for
> 4.03.
>
> Best,
>
> Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20160629/3eece9fe/attachment-0001.html>