Thank you for the considerations and directions for improvement, @avsm.
I'm sorry for the delay in replying, but I was out sick last week.

Regarding opam repo policy and CI change managment

I'd like to start by addressing the point you raise around process:

Overall though, I'd like us to not just push checks into the live opam-repo-ci without at least some consultation about what the checks are first...

It looks like we may need to formalize an explicit process around developing the opam CI and packaging policies. We clearly moved forward without having achieved enough consensus or understanding from various stakeholders in this case, and having a clear, documented process should help us reduce the chance of that recurring. In this case, it may be a growing pain from my recent addition to the maintenance team?

That said, reviewing the (implicit, informal) process, there was certainly some consultation and there were some opportunities for interested parties to weigh in. I think we can improve this a lot tho. I have started some notes and it is on our agenda for the next opam repo maintainer meeting. Thank you for noting the problem!

Regarding the concrete design considerations

how will the check be backported to existing packages?

AFAIK, we already have a precedent for lint checks that are added without retroactively backporting to existing packages (e.g., to exclude pin-depends). It is also is common practice with the introduction of linting checks to incrementally improve the quality of the code base using lints without overhauling all existing code into conformance. To my mind, this can be approached as an incremental improvement on existing or updated packages and and existing packages grandfathered in.

This is not to say that it would not be worth while to consider backports. I just don't see why that would be a prerequisite here.

how do other package managers capture this metadata? is it always email addresses these days?

npm requires registration that calls for an email for package authors. "package owners" (maintainers) must have an npm account.
crates.io requires registration that requires a github account "crate owners" (maintainers) must have a crates.io accoun
pypi requires registration that calls for an email. Their policy for contacting maintainers is via email.
nuget requires registration that requires a Microsoft Account
nix has a more fluid notion of package maintainers. It allows email, matrix ID, or github contact, but one of the three must be provided.

how will the metadata be maintained? do we ping the email addresses every so often?

This is a good question, and would apply to any form of contact I think. It can probably be bucketed along with a more general question of how we ensure home pages, issue trackers, or source archive URLs stay live? Adding something like this into the health check would be great.

we could consider other mechanisms to alert maintainers, such as using the discuss.ocaml.org ids to send messages to maintainers specifically about their opam packages. This works with groups and so on...

Indeed, we could consider any number of mechanisms. IMO, the main benefits of email are:

It is a venerable, virtually universally used, open, free, distributed protocol.
Anyone using the internet has at least one email address and accounts are easy to set up if additional emails are needed with no vendor lock in or walled gardens in he mix.
It is straightforward to automate and semi-automate sending important information to email addresses.
We don't need to ask contributors to register new accounts on any services they don't already use.

I'm not opposed to using discuss (or any other platform), but I cannot think of a more accessible or light weight option than letting people use an email address. I can imagine people or organizations being willing to maintain packages but not interested in registering for our forum or whatever. We could also support any number of different contact methods, but that seems like needless complexity and overhead for maintainers.

Looking forward to hearing any further thoughts on this!

We plan to discuss this at the next opam repo maintenance meeting. I think one key topic to decide there is whether we want to remove this check for now.

Add a linter check for an email address in the "maintainer" field. #152

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions