[opam-devel] ows reports

[Louis Gesbert]

Hi

I think this discussion is going the wrong way.
>From my point of view, OWS was created as an extremely useful tool to help debug packages in bulk and locate some packaging errors.

Then we are mixing it with notions of metrics for the repository quality. I think this is wrong: it can certainly be used to help improve repo quality, and we _could_ either turn it into a repo-quality metrics tool, add that kind of functionality or use it as the basis of such a tool. But it's not that, not at the moment: that's probably a communication error, and the misunderstanding on what the OWS table precisely means at the beginning of this conversation is a clear sign of that.

Therefore, attempts to improve OWS results by tweaking the repo are absurd if that's their only goal.

Note that raw distcheck results may make much more sense as a metrics with single-version repos like that of Debian, which added to the confusion.

I'm opening a new thread to discuss repo metrics from fresh ground.

Cheers,
Louis


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

Yes, this is a bug.

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

Wrong: Red boxes won't show in `opam list -a`; you can still try to install explicitely and get sensibly the same message as in OWS.
(Remark: `opam list -a` shows _installable_ packages. `opam list -A` shows all)

On the classification: we'd need to decide exactly what the categories are, to be discussed on the "metrics" thread.

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

The point is exactly that you get the precise details on these chains of deps by clicking the red box isn't it ?

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

Excellent idea, akin to the "derived function" I mentionned earlier: this is where it makes most sense, finding out wether a given change has an impact on other packages.

The only related issue I could see on the user experience at the moment, is users seeing a package on opam.ocaml.org/packages and getting disappointed when they couldn't install it while nothing said so on the website. The proper way to fix that would be to add distcheck info (and ows links ?) in opam2web to advertise earlier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20141003/79be7045/attachment-0001.html>