Welcome new maintainers of opam repository, and introducing Obi

Community
21

I’m not sure. osX maintainers have been thin on the ground, and the Travis infrastructure is unreliable. Help welcome here…

22

While not a maintainer, I am primarily a MacOS user and would like to find ways I can be more helpful/involved. I’d be happy to be on such a list, if simply having a person willing to go through the build steps is sufficient.

I’ll try to help on the linked PR when I get home tonight, if no one else beats me to it.

1 Like
23

Is there a place to have a discussion on package naming choices, or a procedure on who to ask when the question arises? @UnixJunkie is proposing a new package (GPR#10927) named “consent”, and I personally think the name is terrible. Now that the CI results are okay, should I ignore the bad-idea feeling and merge nonetheless? (Are there people interested in giving an opinion on such questions?)

2 Likes
24

It’s a normal thing to have. The need for it is more apparent when there are so many packages that categorization becomes necessary, as then package submission and categorization easily blurs together – that is, package maintainers are also maintaining the package taxonomy. A decade ago if you wanted to submit a package to CPAN you were advised to discuss your module and its name on a mailing list not used for much else. That was just an advisement: submitters wanted to use it and others wanted to advise you so that module names would be reasonable and useful. Of course, of a do-nothing module with a name like "The::Perl::Comunity::Sucks::Lol", or "Eat::This::<100 megabytes of characters remaining in this module name>", or "; DROP TABLE PACKAGES", corrections would be made. There is no need for a rule like “don’t deliberately pollute our service”, and trying to add rules for abuse will just invite various kinds of rule-fetishist.

But, if you’re interested in a forum that can actively reject names, not just offer advise about them, and not merely about abuse but about someone using names that others dislike for whatever reason, then I suggest you consider

  1. the hours that you will spend arguing that you were justified in saying “no” after having said “no”.

  2. the ease by which someone can fork the entire OPAM system and rerelease it without any kind of onerous gauntlet for package-submitters to go through.

  3. the likelihood of a politically neutral fork like this becoming the most popular module system after yours is clouded in drama.

If what bothers you is the feeling that you are endorsing a name when you merge a PR that adds it to OPAM, maybe a bot can do merges like that.

Alternately, you can exert more control over names and package quality, while encouraging people to want to submit to that control, by having a separate curated list of packages, or by curating some sign of quality that’s shown in normal opam listings of packages. … you know, like Twitter’s blue checkmarks. This would also be of genuine value to the OCaml ecosystem, as it helps package seekers find a probably-good package without having to do lots of research first. Meanwhile, since packages will still be available even if you haven’t given them your seal of approval, you’ll lose fewer hours to arguments about your decisions.

1 Like
25

Thanks for the perspective. I think that the specific situation I’m thinking about (although it’s good to have opinions and feedback on other case that may happen in the future) is, fortunately, quite far from this “should we actively reject or not?”. The question I’m asking, I guess, is whether other people thing that it makes some sens to push back a bit harder on a name, or whether it does sound reasonable to them.

3 Likes
26

Oh OK. Then I agree: this is some kind of extremely niche “chemoinformatics” software but it has a name that suggests that it handles “[Y/n]” queries in a terminal or double-opt-in requirements for email lists. The name fails to

  1. help non-users know it isn’t for them (people looking for graphics software might check it out) and,

  2. at least, it doesn’t have something obvious like chem_ in the name to help potential users find it.

27

Names are hard. What I at least look for are typosquatted names (since there are actual attackers http://incolumitas.com/2016/06/08/typosquatting-package-managers/ https://www.theregister.co.uk/2017/08/02/typosquatting_npm/ https://mail.python.org/pipermail/security-announce/2017-September/000000.html and others).

From https://github.com/ocaml/opam-repository/wiki/PR-checks the only mention is “no ocaml pre- or postfix” (which is unfortunately violated sometimes).

I gave up trying to police any names in there, since I saw several names which IMHO are way too generic (and/or where the description doesn’t explain anything).

28

I think the procedure followed in the PR is sensible. Request the author to change the name in the PR if there is a concern, and if we cannot reach consensus with the submitter of the PR, then the maintainer team will need to make a judgement call on that specific case.

2 Likes
29

Regrading typosquatting: Perhaps we could have the CI scripts check for names that are “similar” to other packages/PRs (levenshtein distance, phonetic matching) and give the author a heads-up if they’re proposing a name that might be confusing.

1 Like
30

On that topic

  • shouldn’t we start by having a list of blessed tags;
  • if no such tag is present when a package is submitted, Camelus would complain an point to the web page explaining them (and the procedure to follow to request new ones);
  • defining a curated list would simply be done by adding a reserved tag to the package (something that Camelus could check — the blessed tag can only be present if the previous version has it — and/or automatically add — if the previous version was blessed but the maintainer did not put the tag, Camelus would add a commit).

Given this, building a curated categorized list of packages could be done automatically by a script.

1 Like