[opam-devel] current opam-repository policy : who can modify a package description

[Thomas Gazagnaire]

> * the future authentification system for opam-repository will prevent anybody, except maybe admins, from modifying somebody else's package. Thus, the current policy will not be possible in that future;

That was not my understanding of the proposal: any PR modifying anything can still be merged as long as there is a quora amonst the repo maintainer. I think that was part of the design constraints that Louis and Hannes tried to resolve.

> * when a packge description is updated without the owner knowing it, it can lead to inconsistences (the owner might update the package later without applying the patch, or propose a new version without the patch, thus leading to a regression) and the owner might not learn about the problem (it happened to me this week-end, as I would have not known about a regression in ocp-build if I had not noticed a PR on ocp-index that uses it).

It is indeed important that upstream are aware of issue and we currently do a poor job with that. Would be nice to automatise that by sending emails to maintainers. Anil, can we use @ocaml.org <http://ocaml.org/>'s SMTP for that?

> * a maintainer's fix might be of less quality than an owner's fix, because he might not know why something is done or not done. Discussing with the upstream developer usually is thus a better approach.

After having spend years (literally) fixing issues in opam-repository, I disagree with that statement. Repo maintainers are experienced OCaml coder, which see compilation error pattern every day. Repo maintainers are also quite active (usually more than package maintainers) and fix issues when they see them.

> For all  these reasons, I propose to switch to the strict mode. Of course, some fixes are still possible directly by maintainers, such as fixing broken urls (without changing the checksum). These exceptions should be specified too.

I think the current model has some flows but it's still very valid given the current constraints. As I said in an other thread, this is a local optimum. Of course, I'm fine to move to another local optimum if it's better :-)

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20160222/a26d1eff/attachment.html>