[opam-devel] ows reports

[Fabrice Le Fessant]

Hi Thomas,

On Wed, Oct 1, 2014 at 10:57 AM, Thomas Gazagnaire
<thomas at gazagnaire.org> wrote:
> Agreed. My goal is that it should be possible to make *all* red cells
> disappear (which is not the case currently), because that's the metrics that
> people start using when they speak about the quality of opam packages.

Indeed, it is a good metrics to complement Travis testing.

> Also I've noticed that packages which are not installable because they are
> not available on all compilers do not appear in the list. I think they
> should appear there, as it's usually an error in their metadata (see
> lablgtk-extras 1.2, 1.3 and 1.4, that I've just fixed).
>
> Louis, Instead of the derived function, maybe we can apply to all "broken"
> packages a post-processing step to classify them using the same function as
> you wrote to reports conflicts / unavailability errors to the user?

  I don't think this is going to work: red boxes in OWS have a clear
semantics, from the user point of view, it means that 'opam list' is
going to show the package with the corresponding version as available
for the current switch, but 'opam install PACKAGE.VERSION' is going to
fail. That's bad user experience. Changing the red box into an orange
box is not going to change this bad experience for the user.

  Moreover, the reasons for a failure may me mixed: if package A
depends on B, and there are two versions of B, one depending on C with
a version of C that does not exist, the other one with a version of C
that is not available for the current compiler, what would be the
reason for A not being installed ? Something has to be done, either
adding a new version of C, or porting the old version of C on the
current compiler, maybe adding a new version of B, or dropping the
dependency on B for A, but whatever it is, OWS is not going to give an
advice. It will just say "A is broken" and put a red box.

  Actually, it would be nice to run `distcheck` twice for every new
pull-request: once to compute the number of broken packages before the
commit, and once to compute the number of broken packages after the
commit. This way, only pull-request decreasing the number of broken
packages would be accepted. This could be part of a general
`opam-repo-lint` tool, that would also verify that every package
description is smaller than 50 kB (ref. Coccinelle), and call
`opam-lint` on every `opam` file.

Best,
--Fabrice