Consider replacing concerns with dedicated classes & composition

I read https://blog.codeship.com/when-to-be-concerned-about-concerns/ this morning and there are some pretty good points about:

• Using composition
• Limiting interface

We should start with a POC to show the advantages and how we could apply this broadly instead of moving stuff to concerns, in most cases just because some of the code is reused or because the main class becomes too big.

/cc @rspeicher @grzesiek :)

Good article, makes a lot of sense.

@rymai I think that composition makes much more sense in many cases than inheritance. Using concerns is multiple inheritance which is even more complex. for using composition over inheritance (when relation between objects is contains something instead of is something).

@rymai @rspeicher Actually this issue https://gitlab.com/gitlab-org/gitlab-ce/issues/13484 is mostly about using more concrete classes. See https://gitlab.com/gitlab-org/gitlab-ce/issues/13484#note_3777545 in particular.

Mentioned in issue #23865 (closed)

This is probably going to be a long ongoing work as well. Some of my offenders come to my mind:

• CreatesCommit
• ExtractsPath

Basically ALL modules which use instance variables coming from no where. Perhaps we could start by trying to stop people adding more modules with instance variables?

This issue seems to be still valid https://gitlab.com/gitlab-org/gitlab-ce/issues/13484.

Yeah, there are a lot of ongoing works and discussion, and I am a bit unsure if we could consolidate them into a single issue or at least make it more clear what we're going to do. I don't think we should make another meta issue though, in case of yet another meta issue lol Unless we're going to close some of them.

mentioned in merge request !12800 (merged)

Hi @rymai,

First of all, thank you for raising an issue to help improve the GitLab product. We're sorry about this, but this particular issue has gone unnoticed for quite some time. To establish order in the GitLab-CE Issue Tracker, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.

This issue will be closed, as it meets the following criteria:

• No activity in the past 12 months (since 2017-09-18T06:59:11.903Z)
• No milestone (unscheduled)

We'd like to ask you to help us out and determine whether this issue should be reopened.

If this issue is reporting a bug, please can you attempt to reproduce on the latest version of GitLab or GitLab.com, to help us to understand whether the bug still needs our attention.

If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.

Thanks for your help

Improve this comment

/cc @gitlab-org/issue-triage

added auto updated awaiting feedback labels

Let's keep this until we get there.

added maintenancerefactor priority4 severity4 labels and removed auto updated awaiting feedback labels

added backstage [DEPRECATED] label

added [deprecated] Accepting merge requests label

removed [deprecated] Accepting merge requests label

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue