Only allow classes and modules directly under the Gitlab namespace for truly cross-cutting concerns
In #212156 (closed) / !51236 (merged), we required all new classes to be namespaced. This is because, say, an Issue class might mean different things in the different domains that GitLab operates in.
However, one get-out for this is the Gitlab namespace. We have a lot of classes and modules directly under this namespace: https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab. Anything under here won't be detected by the previous MR, because it's not at the top level. But it being nested under Gitlab::
tells us nothing about the domain.
Some of these will be fine: they will represent items that aren't part of any domain except GitLab-the-application as a whole. Gitlab::Popen
is a reasonable example here.
However, we also have things like Gitlab::SubmoduleLinks
, which clearly belong to a particular domain (Category:Source Code Management), and we should be able to detect and move those over time.
In !51236 (comment 485374321) @fabiopitino suggested a general reorganisation:
The problem is that
Gitlab::
contains both domain code as well as infrastructure code. These 2 layers should live in different directories.One goal we could aim to is to eventually move to a different directory structure like:
domains/ ci/ models/ controllers/ finders/ lib/ merge_requests/ issues/ projects/ gitlab/ auth/ database/ elasticsearch/
Where each domain has its own lib folder. This means that classes like
Gitlab::Ci::Config
will become simplyCi::Config
as it's part ofCi::
domain. ThenGitlab::
namespace will represent the infrastructure code.
Which might be a good goal to aim for. For now, we can update the existing check to ignore Gitlab::
, perhaps?