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

[Fabrice Le Fessant]

On Mon, Feb 22, 2016 at 11:30 AM Thomas Gazagnaire <thomas at gazagnaire.org>
wrote:

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

Even the notion of repo maintainer is weird: we should target a completely
distributed repo, where each package is taken care of by a small set of
maintainers (as it is done in Debian, which is not perfect, but working).

Imagine if Github decided that, as they are at least as smart as the devs
who use their platform, that they should have the right to patch whatever
code is hosted on Github. Would you keep using such a platform ? I think
it's the same here: I don't want anybody to mess with my packages, but I do
want to be warned if there is a problem that I should fix.

I think the opam repo maintainers have one opportunity to fix packages
(when a new version is submitted the first time), but then, they should not
be permitted to modify them anymore, without the permission of the
submitter.

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's SMTP for that?
>

What are you proposing ? Indeed, we should have a daemon watching the
repository and sending automated emails for some kind of simple problems.


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

Well, if your goal is to spend more and more time fixing problems in the
repo, that's probably the best approach. But if you want to move the work
from the repo maintainers to the package maintainers, then you need to
spend a little more time communicating with them about such issues. I think
the strict approach is better to spread knowledge, and thus on the long
term. And automatisation can help a lot !


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

Yes, let's find a better local optimum :-)
--Fabrice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20160222/23d3844f/attachment.html>