> * 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
_______________________________________________
opam-devel mailing list
opam-devel@lists.ocaml.org
http://lists.ocaml.org/listinfo/opam-devel
