Just a thought. The inclusion of a package in METADATA is currently conditional only to formal considerations… if the tag is in the right format, if the require file is present and so on… but no “judgment” on the quality of the code nor on the relevance of the package is made.
While I appreciate this “open” approach, I also appreciate those when some sort of QA is employed.
In particular I liked the experience I had to develop Drupal modules (Drupal is a web Content Management System). In that case, the first time a developer propose a module, this is put in a sort of review system, where peers gives her suggestions on how to improve her code or better follow guidelines.
After this first module is approved, the developer can then submit other modules without further review.
Would this model be applicable also for packages of generic programming languages as Julia, or do you think it would be too ambitious ?
In the discussions about 1.0, around the work on Pkg3 (replacing the current package management) there is sometimes the notion of a standard library, or a list of curated packages and some ‘light pressure’ to overcome package fragmentation. But … someone needs to spend this effort.
I recently went through something similar when I submitted julia-repl to MELPA. I am in two minds about this: I did get a lot of helpful suggestions which made the code more compatible across Emacs versions, but at the same time it was clear that the people helping me were very busy otherwise, which resulted in delays (my fault too, of course).
Instead of making it mandatory, it could be started as a voluntary scheme: people could ask for code reviews, and get help from experts. OTOH, I imagine that all the developers qualified to do this are very, very busy, and perhaps think that their time would be better spent improving Julia or the packages they contribute to.
In any case, I find reading Julia code of various packages very helpful. I learned a lot this way about optimization, code organization, and mundane details like setting up the documentation.
Well, I am just trying to open a discussion on whatever such model would be transferable from a system where modules refer to a specific context, to a generic programming language, where packages could be about everything.
Also, I am not speaking about a specific package management, just the policy for the inclusion of the packages.
While obviously what gets maintained will depend on people’s availability, I do think it would be a good idea to maintain a highly visible list of packages that are known to be maintained. JuliaObserver does this to some extent, it might be a good idea to have a link to it on the main Julia website and github.
I don’t really think that quality assurance of all registered packages will ever work. The only people who can really asses package quality are its users, and there’s very little chance that one of them will be in a review team.
I also fill somewhat uncomfortable when I have to wait for several days when my package gets registered / new version is approved to include it into requirements of a dependent project. Instead in practice I keep many changes untagged for a long time so users have to checkout master of several packages to make things work. What’s worse, I see the same pattern on many other packages, so perhaps it’s not just me.
Having said that, I support the idea of a list of high-quality and actively maintained packages that newcomers may use without risk of getting negative first impression.
I support the idea of a list of high-quality and actively maintained packages that newcomers may use without risk of getting negative first impression.
Yes particularly for plotting. When I leave Julia for a month or two as I get caught up in life, I can never remember which plot package to use…
