search

ocaml-opam / Camelus

Bot posting reports on opam-repository pull-request using a web hook
Other
18 stars 9 forks source link

Ping the maintainer of a package when it's modified #16

Open dbuenzli opened 7 years ago

dbuenzli commented 7 years ago

Many people want that.

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

https://github.com/ocaml/opam-repository/issues/6819 https://github.com/ocaml/opam-repository/issues/4897

AltGr commented 7 years ago

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

hannesm commented 7 years ago

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:

let me know once you settled how/whether this should be done.

dbuenzli commented 7 years ago

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 commented 7 years ago

The maintainer info is just free-form strings, so that could be added there as well: maintainer: "Foo Bar <foo@bar.com> @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 commented 7 years ago

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 commented 7 years ago

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 (@hannesm 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).