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

[Louis Gesbert]

Just bringing in some clarifications:

- Hannes summarised the signing plans well. I'd like to mention that anyone 
can still file a PR across packages they don't own -- in that case, a quorum of 
repository maintainers will need to sign it (which, with proper tooling, 
should'nt be much more than command-line). If they only modify packages they 
own, they can sign for it, and obviously still need the PR accepted, but 
that's it.

- Notifications: Camelus already detects modified package definitions and has 
access to the maintainer field -- just adding notifications through some SMTP 
binding would be easy. Something in the vein of « A pull-request modifying 
package Xxx has been submitted by Yyy », with the diff and a link to the PR. 
Then leave some time window for the owner to chime in. That's assuming mails 
aren't obfuscated in the metadata, we should probably put some obfuscation in 
opam.ocaml.org/packages to help with that. contact at ocamlpro.com is going to 
get (o)pammed :p.

- Another, more subtle notification, is that `opam update`/`opam upgrade` can 
tell you about modified upstream metadata. It could even warn or advise if the 
in-source opam is not in sync (it's already done in some cases).

- It's not the only one, but adding upper bounds on releases of a new version 
of a dependency is indeed the main case for cross-package patches. Solutions 
are welcome, e.g. forcing an upper bound on dependencies to begin with, but 
should be considered carefully within our existing setup, which is very agile 
and has its merits.

- There is an awfully complex net of dependencies: I think managing it in a 
completely distributed fashion would be much more difficult than it is now. And 
editing packages with full control and responsibility is available through 
`opam repo add`. Systems like npm can discover packages and don't require a 
central repository, but we have stricter interface constraints, and having a 
board of editors trying to keep the consistency of the whole is I think a good 
thing. Now, of course, this all needs the right balance.

Best,
Louis Gesbert - OCamlPro

Le lundi 22 février 2016, 12:23:19 Fabrice Le Fessant a écrit :
> 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