Update package registry direction page and priorities

Why is this change being made?

TLDR: We need to revisit our priorities for devopspackage

Overview

Sidney wants to rely solely on GitLab as a universal package manager so that they can reduce costs and drive operational efficiencies. However, GitLab only supports privately hosted package repositories, which only accounts for half of their team's use cases. In addition, the naming conventions enforced by the GitLab Package Registry, make it impossible for organizations with many teams and many developers to use GitLab’s offering.

Remote/virtual repositories are a key missing feature when comparing GitLab to Artifactory/Nexus and have been identified as a core requirement of several enterprise customers.

In addition, as adoption has grown for NuGet and Conan, we have seen an increased amount of issues and negative user sentiment that needs to be addressed. I expect the same will be true as we see increased adoption of PyPI and Composer.

Proposed prioritization updates

1. ⬆ Remote and virtual repositories

2. ⬆ Resolve issues with NuGet and Conan

3. ⬆ Ensure users can authenticate using a job token. (NuGet, PyPI, Composer)

4. ⬆ Ensure we are measuring usage and adoption.

5. ⬆ Limits and quotas for our existing integrations

6. ⬆ Generic package manager

7. ⬆ Policies to prevent the download of suspicious packages

8. ⬇ Caching of external dependencies

9. ⬇ Ruby, Debian, and RPM integrations.

Implications

The implication of the above is that we will delay our planned RubyGems, Debian, and RPM integrations.

Caching of external dependencies was stated as an important requirement, however not as important as remote/virtual repositories or the ability to define and enforce limits and policies for which packages are downloaded.

Pros

• Give the product developers the opportunity to focus on this significant architecture change.
• Build a product that works as a universal package manager and allow our customers, using one of our supported formats, to replace Artifactory.
• Advanced policies and caching could be considered Premium features.

Cons

• These are all important dogfooding features for the Infrastructure and groupdistribution teams. They presently have functional, satisfactory workarounds.
• They have all been requested by customers and prospects.
• Basic support for new formats could increase our cross-stage usage by allowing new sets of Developers to start using the Package stage.

Data

Programming languages on GitLab.com

• The above chart displays the share of programming languages on GitLab.com. It does not include self-managed customers. It does not guarantee future usage.
• Ruby is used in 5% of GitLab.com projects.
• Our current integrations support the most common languages:
  • Javascript (41%)
  • Java (16%)
  • PHP (16%)
  • Python (16%)
  • C/C++ (11%)
  • C# (6%)

GitLab Prioritization

Referencing the GitLab handbook, it's clear that we should prioritize availability, features promised to customers prior to dogfooding and velocity of new features.

Community contributions

~"group::package" will focus on improving support for our existing integrations, we are accepting contributions for any new package manager format. We have clear documentation and examples for reference and regularly host community office hours to help contributors along.

Other

We will need to build a generic package manager to help any user publish and install any type of file and bundle them with releases.

Author Checklist

• Provided a concise title for the MR
• Added a description to this MR explaining the reasons for the proposed change, per [say-why-not-just-what][transparency]
• Assign this change to the correct DRI
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to your manager.
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in [#mr-buddies][mr-buddies-slack].
  • If the changes relate to any part of the project other than updates to content and/or data files please make sure to ping @gl-static-site-editor in a comment for a review and merge. For example changes to .gitlab-ci.yml, JavaScript/CSS/Ruby code or the layout files.