Package Updatability and Hosting considerations

[henilp105]

Package Updatability :
Should we consider keeping the packages mutable ? ( if yes , I would only like to keep the parameters isDeprecated only as mutable as keeping other parameters mutable might raise a lot of vulnerabilities and threat scenarios) , But for some Exceptional cases we would like to give admins power to change all the parameters of package.

Backend Hosting considerations :
I have currently hosted on vercel, it works very well and heroku both can work as great alternatives to AWS ( our earlier consideration) to reduce costs and also help in easy maintainability.

Mongodb Hosting considerations :
I have currently hosted on MongoDB Atlas it works very well and also gives good interface to the database (for easy access than a docker container) , But it adds slight latency to the APIs requests. But It would be easier to manage and would help minimise the downtime that we might have in our mongodb containers.

I would like to request all the Community members to review and add suggestions.

Thanks and Regards,
Henil

CC @awvwgk @fortran-lang/admins @fortran-lang/fpm @arteevraina @perazz @minhqdao

[everythingfunctional]

I would only like to keep the parameters isDeprecated only as mutable as keeping other parameters mutable might raise a lot of vulnerabilities and threat scenarios) , But for some Exceptional cases we would like to give admins power to change all the parameters of package.

I agree with this.

I used Heroku for a project a few years ago and had good luck with it. If I recall they offered a managed database service to go along with an instance. Might be worth looking into doing it that way.

[arteevraina]

Some of the ideas discussed in the last weekly check-in that we discussed:
So, a user can have four roles in the registry: "admin", "maintainer", "author" and "user".

• Admin (of a namespace) - should be given the authority to change the metadata(description, tags, links) of the packages in the namespace. Admin can also directly create a new version release of a package without requiring any more permissions. And admin can also toggle the is_deprecated flag of the package.

• Author: If a user is the author of the package, then the user can have all the authorization that the admin has but only on the package that he is the author of. While on the other hand, admins can have that authority over all the packages in the namespace.

• Maintainer: Maintainers, on the other hand, should not be able to change the metadata of a project. But, they can be allowed to create a release that the admin has to approve, and only then the release can be completely published to the users.

cc: @minhqdao @henilp105 @perazz You can also add some points if I missed something.