Curated registries would be nice!
The good news: anybody could start such a registry. Realistically, I could see these by domain. For example, SciML could have a registry for “the best packages for numerical simulation”. Or the JuMP community one for “the best packages for optimization” (not just the packages from those orgs, but the wider ecosystem). Whether there’ll ever be a “curated General”, focusing on packages that have been formally reviewed is doubtful. There isn’t really any “staff” or volunteer bandwidth to do such reviews.
One point to be clear on: The current General registry is, and will continue to be “lightly curated”. It will probably move to “slightly more curated” over time (I really think we should require tests, for example), but no level of quality is guaranteed, and package quality will fluctuate and depend on the availability of community volunteers. The General registry will always be “permissive”, in the sense that any package with an appropriate name and an easily achievable minimum level of quality will be able to register in General, without restrictions or gate keeping. But the General registry is not a complete “free for all”; it is less permissive than e.g. PyPI, but far more permissive than e.g. CRAN.
Maybe a better idea (as has been discussed before) would be to have tags. E.g., “JOSS reviewed”, or “Won community prize at JuliaCon”. That does seem more feasible than setting up an entirely new registry with a curation team.
Regarding ‘control of the “curated” version always belongs to the curation committee’, I would point out that this is true by definition for any registry, by virtue of registries being git repositories. Whoever has commit access to the git repo controls the packages and versions in that registry. For the General registry, that’s the Julia core developers who originally set up that registry, and the people that have since been voted in by existing registry maintainers to become new registry maintainers. Importantly, there’s also an AutoMerge bot that has commit access, and this is how most registrations are added. At the end of the day, package maintainers have to trust registry maintainers to manage the registration of their package. For the General registry in particular, that’s a trust that the maintainers of General act in the interest of the broad community, without excessive gate keeping. I don’t think it’s something to particularly worry about, but still: package maintainers do not “own” the registration of their packages in the General registry, or any registry they haven’t set up themselves, in the strictest sense.
I could realistically see something happening at the other end of the spectrum: It would be nice to have an official “test registry”, similar to how Test PyPI relates to the normal Python package index. This would have the same setup as the General registry, with the same AutoMerge bot, except that a package submitter could always add a comment to override the bot. That is, all installable registrations would be guaranteed to automerge. The point of such a registry would mainly be to test whether a submission is going to pass through the automerge of the full General registry, to enable the easy development of multiple interdependent packages that are not quite ready yet to be submitted to the full General, and to be able to set up all development workflows around “making releases” before the package is ready for General. All of those things would make it much more realistic to make “don’t register in General until you’re ready for 1.0” a possible social norm.
Somebody would have to set up such a Test Registry, though, so, no promises that anything like that will ever happen.
P.S.: it may not be obvious, but the same package can be in multiple registries. The only restriction is that all registries have to associate the same tree hash with the same version number for the same package uuid