Breaking change exception: Delete an obscure, 2 year broken rake task
Breaking Change Exception Request
Executive summary
An old, incomplete, not-recommended procedure for migrating GitLab instances instructs you to use rake gitlab:list_repos
. That rake task has only raised an error for the last 2 years. The existence of this rake task blocks some Gitaly effort until it is removed.
I propose we remove the rake task and its docs immediately since it is:
- the cheapest action
- there is no notable benefit to be gained from deprecation
Impact assessment
How many customers are impacted?
Very few. Based on the 1.5 year old issue with the error message, someone comments or thumbs up every 1 or 2 months on average.
Can we get the same outcome without a breaking-change?
- GitLab.com and other company instances: No impact because we don't use it.
- Self-managed on pre-removal versions: No impact because the broken rake task still exists for them.
- Self-managed on post-removal versions: No impact because this group would read post-removal docs, which won't refer to the rake task.
- Self-managed on post-removal versions who remember this rake task: No impact because the last time they tried it, it only raised an error. They therefore did not build any tooling or procedures that depend on it.
An alternative is to delete the docs, announce deprecation of the rake task, schedule removal of the rake task. This is more work, delays other progress, for no known benefit.
Even if we fixed the rake task or worked around it, the outdated migration procedures would need to be updated to consider that GitLab contains more than just Git repositories.
Can the breaking-change wait till the next major release, or the next scheduled upgrade stop?
It can. This change is not urgent, it is just efficient.
What is the alternative for customers to do the same job the change will break?
The "Recommended approach in all cases" is to use backup and restore. There are also 2 other non-recommended options, 1 and 2.
How difficult is it for customers to migrate to the alternative? Is there a migration plan?
The already-recommended procedure is to use back up and restore, which is not only easier, but it is complete.
Communication plan
Tasks
-
Notify Support and Customer Success so they can share information with relevant customers. -
Obtain approval from the VP of Development, VP of Product Management, and VP of Customer Support for this area -
Obtain approval from the CPO or CTO