Ping the maintainer of a package when it's modified

[dbuenzli]

Many people want that.

Here are a few relevant discussion occured on the opam-repository tracker.

ocaml/opam-repository#6819
ocaml/opam-repository#4897

[AltGr]

Should be easy with @hannesm's great work in building a database of the contributor's github idents.

[hannesm]

On 07/07/2017 14:30, Louis Gesbert wrote: Should be easy with @hannesm's great work in building a database of the contributor's github idents.

as mentioned elsewhere, I can open a PR to add the metadata to opam files of the opam repository. You have to decide where to put them: - if we want to use this in opam1, tags/maintainers/authors fields come to mind (tags: [ "GitHub:@foobar" ]) - opam2 only x-github-maintainer: "@foobar" let me know once you settled how/whether this should be done.

[dbuenzli]

I guess the answer is no, but I'm just writing this to make sure it is the case.

Isn't there any API call on gh that allows to retrieve the gh user name of the email mentioned in maintainer: and if not did anyone try to submit an issue for that ?

If we could avoid having to multiply redundant information in the metadata fields and this to only support the system on which the opam-repository happens to be currently hosted I wouldn't mind.

[AltGr]

The maintainer info is just free-form strings, so that could be added there as well:
maintainer: "Foo Bar <[email protected]> @foobar"
if we go that way, we can't expect new submissions to follow the format though (although opam-publish could help)

If there is an API call, that would be nice of course. But the data here is due to become part of the repository, as it will identify signing keys (with name and email being just metadata). The fact that they match github ids is very convenient for us, but won't be a requirement of the system (@hannesm please correct if I am wrong).

[dbuenzli]

But the data here is due to become part of the repository, as it will identify signing keys (with name and email being just metadata).

If it's needed I rather have that cleanly in a separate field. My issue is not adding new fields my issue is denormalized data.

[hannesm]

On 07/07/2017 15:02, Louis Gesbert wrote: But the data here is due to become part of the repository, as it will identify signing keys (with name and email being just metadata). The fact that they match github ids is very convenient for us, but won't be a requirement of the system ***@***.*** please correct if I am wrong).

There's no required relation between GitHub ids and packages for Conex. The current design (as implemented) keeps the authorised names to modify in a separate "authorisation" file for each package. Each "name" has a mapping to a public key (and has a GitHub identifier as metadata, not required). In the next design (this month! - after discussion with the TUF people) I'll get rid of these intermediate "names" (and store "authorisation" elsewhere).