[opam-devel] ows reports

[Thomas Gazagnaire]

>> 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.

Then the table is inconsistent:

$ opam install typerex.1.99.6-beta
[ERROR] typerex.1.99.6-beta is not available because it requires OCaml < 4.02.0.

opam returns an error, but the box is "white" on ows. Following your logics, it should be "red".

Usually users request a package name, not a specific version of a package. ows doesn't make the difference between "all versions are broken" and "the version X is broken" which is a far worst user experience.

Now, from a repository maintainer point-of-view, if someone creates a new metrics and advertises it by saying "look how bad it is", I guess the goal is to make some changes (the policy, the workflow, ...) to improve the metrics results or at least to propose or explain how it can be improved -- if not, I don't see the point. Currently, it is still unclear to me how we (the repo maintainers) can fix all the "broken" packages on the repo without requiring all packages to compile on all the versions of the compiler (which will never happen) or by duplicate metadata (the transitive closure of the available fields) which will get out-of-sync quickly.

>  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.

These are the interesting packages which should be brought to attention to the maintainers. Not the other 99% of packages which are unavailable by transitivity (and reported as such by opam), especially when a more recent version of this package exists and fix the availability issue.

>  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.

Any tool to help us triaging incoming pull-requests is more than welcome.

Best,
Thomas