Migrate Alizer to Devfiles organization

[mike-hoang]

Which area/kind this issue is related to?

/kind epic
/area releng

Issue Description

Migrate Alizer from redhat-developer to the devfile organization.

Create a new repo devfile/alizer with a clone of redhat-developer/alizer, which is then marked as deprecated. Users then have to manually switch to the new import path when they want to upgrade to the non deprecated version.

Related: Post onboarding actions #239

Acceptance Criteria

• Create devfile/alizer with a clone of redhat-developer/alizer
• Flatten structure of the Project after the removal of JS and Java #177
• Update devfiles processes after alizer migration devfile/api#1148
• Add a notice to readme - adding deprecation warning to readme #255
• Archive redhat-developer/alizer

[mike-hoang]

Two approaches for the migration from Alizer to Devfiles:

Approach 1 - GitHub "Transfer ownership"

Using the Transfer option in the repo settings, GitHub will automatically redirect all traffic from https://github.com/redhat-developer/alizer to https://github.com/devfile/alizer.

https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository

Pros

• Quickest / least amount of work for users
• Transfers all history: issues, prs, starts, watchers, contributions, web hooks, secrets, deploy keys

Cons

• Renaming the go.mod module name will still result in users needing to change their go.mod (i.e. if we want to flatten the repo structure)

➜  test-alizer git:(main) ✗ go get github.com/mike-hoang/alizer-copy/go@09ec9e5
go: downloading github.com/mike-hoang/alizer-copy v0.0.0-20230626152052-09ec9e515baf
go: downloading github.com/mike-hoang/alizer-copy/go v0.0.0-20230626152052-09ec9e515baf
go: github.com/mike-hoang/alizer-copy/go@v0.0.0-20230626152052-09ec9e515baf: parsing go.mod:
        module declares its path as: github.com/thepetk/alizer-copy/go
                but was required as: github.com/mike-hoang/alizer-copy/go

Approach 2 - Duplicate Alizer

Create a new repo devfile/alizer with a clone of redhat-developer/alizer, which is then marked as deprecated. Users then have to manually switch to the new import path when they want to upgrade to the non deprecated version.

Pros

• Allows for major changes without breaking existing users; repo structure can be flattened (changing module github.com/redhat-developer/alizer/go to module github.com/devfile/alizer)

Cons

• Will lose all history from above (will still have the git log)
• Will need to recreate all issues
• Extra work for users

[michael-valdron]

I'm leaning towards Approach 2 - Duplicate Alizer because it will allow us to preserve the old imports for the users preventing things from breaking as well as allow us to do the refactoring changes in the new location.

Two things that concern me a bit about this approach but perhaps is workable:

1. Spotty migration of item history, particularly issues and PRs
   • Could be doable through tools and linking old items to the new ones
2. Ensuring users switch to devfile/alizer for further changes
   • We should public archive redhat-developer/alizer and indicate that is deprecated if we choose this approach

[thepetk]

I'd say too approach 2. If we follow this approach the current issue should be transformed to an EPIC. Actions regarding the epic could be

• We can create a new repo and import existing alizer's code.
• Complete Flatten structure of the Project after the removal of JS and Java #177 and merge to the devfile (new) repo.
• Migrate all open issues to new repo. Then we can close the old repo's issues, by linking them to the new ones
• We could also move the closed issues by just having a link to the archived version.
• Create first release of new repo (v1.0.0)

[UPDATE]

• Update documentation to the old repo and explicitly mention that the repo was moved.

[thepetk]

I am preferring the reverse, having a link to the active issue in the archived ones, but any linkage is good.

No I think you are right. Each old issue must be closed afterwards and a link should be added to them referring to the new repo.

I've updated the comment

[michael-valdron]

I am preferring the reverse, having a link to the active issue in the archived ones, but any linkage is good.

No I think you are right. Each old issue must be closed afterwards and a link should be added to them referring to the new repo.

I've updated the comment

Sorry misread your original comment and removed my comment, yeah we should link the old items to the new.

[mike-hoang]

@elsony @thepetk If we decide on approach two, I can convert this to an epic and create the new Alizer repo in the Devfile org