Preserving issue label history when labels are renamed or removed

On issues where a system note references a label which no longer exists, we see currently something like the following (from #22921 (closed)):

We have no way of knowing what ~19492 used to point to, and it just looks arcane and ugly to someone who doesn't understand the ~labelname syntax.

I propose that instead of using label IDs when creating system notes, we use the ~"label name" syntax instead. This way we can continue to render them as labels, and we can even remember their name, e.g.:

Since we don't have a label to reference, we won't know its original color or description. That's fine, we can just make it a muted gray color and have the tooltip reveal that the label no longer exists:

The only downside to this is that labels which are renamed won't track the same way they do with their ID-based approach now, but I think I'd rather see the label name that was assigned when the system note was created rather than the label as it is named currently. If we want to see the current label name, we'll still see that in the issue metadata on the sidebar.

@smcgivern Is this what you are digging into at the minute?

Interesting idea! I think that renaming labels is probably roughly as common as deleting them, and deleting them (as you say) looks far worse.

@DouweM wdyt?

The only downside to this is that labels which are renamed won't track the same way they do with their ID-based approach now, but I think I'd rather see the label name that was assigned when the system note was created rather than the label as it is named currently. If we want to see the current label name, we'll still see that in the issue metadata on the sidebar.

@mikegreiling I disagree. When a label is renamed, the implication is that the label still holds the same semantic meaning, which means that Added [old name] and Added [new name] should communicate the same concept to the user. If we rename Frontend to frontend or Backend to Platform (as has happened), someone reading the issue after the fact doesn't need to care that that label previously had a different name, and they definitely shouldn't be mislead to think that the label by the old name was actually deleted, as in: it was decided that label wasn't needed anymore.

Perhaps we should include both name and label to support both deleting and renaming :)

@DouweM I think that's not so bad if we simply don't add the tooltip at all, or add a tooltip that says the label name is not found.

Perhaps we should include both name and label to support both deleting and renaming :)

Either way, this sounds like we'd be doing special label rendering for labels that don't exist in system notes. Just using the label name won't cut it, although the default case would be slightly friendlier (we don't want to do that in normal comments because ~foo doesn't render, and we don't know if it ever existed).

So given that we already have these system notes, we could just replace ~123 in a system note (after rendering existing labels) with 'a label that no longer exists' or something? Otherwise it seems like a lot of effort for pretty minor gain, and we'll never be able to rewrite the old system notes anyway.

So given that we already have these system notes, we could just replace ~123 in a system note (after rendering existing labels) with 'a label that no longer exists' or something?

@smcgivern Sounds reasonable!

@victorwu I'll let you prioritise this as you see fit!

added Accepting Merge Requests label

changed milestone to %Backlog

I think this design is great: https://gitlab.com/gitlab-org/gitlab-ce/uploads/a0ccc0275598b70d3915d7aca4e82ee2/tooltip.png.

And it solves the use cases: (1) The label has been removed. (2) What was the name of the label before it was removed.

Just to be clear, as in the design mockup, we do know that "Frontend" was the last name of the label before it was removed, and thus, can render it in the system note?

I think we should choose a different color then just grey to more obviously indicate that it's removed. Since we can choose grey when creating a label right? Maybe some type of hashed pattern?

removed milestone

marked this issue as related to #35195 (closed)

mentioned in issue #35195 (closed)

mentioned in issue #36952 (closed)

marked #12625 (closed) as a duplicate of this issue

mentioned in issue #12625 (closed)

moved to gitlab#10148

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