Move ghw from jaypipes to go-hardware Github Organization

[jaypipes]

I've been thinking about doing this move for a little while. Some organizations (including my own employer, Microsoft), avoid importing libraries from personal Github organizations. They consider (wrongly, IMHO) repositories falling under personal Github accounts to be "less than" repositories that are maintained by multiple parties in a separate Github Organization.

I have owned the go-hardware dot com and go-hardware dot org domains for quite some time and I have created a Github Organization called "go-hardware". I'm strongly considering "moving" the github.com/jaypipes/ghw repository to the github.com/go-hardware Github Organization and getting ghw to a 1.0 release under the github.com/go-hardware umbrella.

I'd like thoughts on this, particular on whether it's worth it, considering we have 1500+ Github stars and >440 projects that import the ghw codebase.

We could minimize disruption by making a clean break from the github.com/jaypipes/ghw codebase and making a completely new github.com/go-hardware/ repository with the inspection/discovery code that is already in github.com/jaypipes/ghw. We would leave github.com/jaypipes/ghw for some amount of time but mark the README as the code has moved to another location and then eventually archive the repository?

This clean break would be backwards compatible since we won't be "moving" anything... we'd essentially be starting a new project and encouraging users to change their imports to the new location. And an approach of building something new under the github.com/go-hardware umbrella would give us an ability to work on things like the resource usage stuff in a different repo or module.

Thoughts?

/cc @ffromani

[ffromani]

I've been thinking about doing this move for a little while. Some organizations (including my own employer, Microsoft), avoid importing libraries from personal Github organizations. They consider (wrongly, IMHO) repositories falling under personal Github accounts to be "less than" repositories that are maintained by multiple parties in a separate Github Organization.

I share the same experience; in my case repos backed by orgs (vs backed by individuals) are "just" strongly preferred. The perception is that the bus factor for orgs is bigger than for individuals, but there's actually a ton of nuance here; nevertheless, this perception exists and we need to deal with it.

I have owned the go-hardware dot com and go-hardware dot org domains for quite some time and I have created a Github Organization called "go-hardware". I'm strongly considering "moving" the github.com/jaypipes/ghw repository to the github.com/go-hardware Github Organization and getting ghw to a 1.0 release under the github.com/go-hardware umbrella.

I'd like thoughts on this, particular on whether it's worth it, considering we have 1500+ Github stars and >440 projects that import the ghw codebase.

We could minimize disruption by making a clean break from the github.com/jaypipes/ghw codebase and making a completely new github.com/go-hardware/ repository with the inspection/discovery code that is already in github.com/jaypipes/ghw. We would leave github.com/jaypipes/ghw for some amount of time but mark the README as the code has moved to another location and then eventually archive the repository?

I think this is the best approach because this is the one which best serves the current userbase. We can wrap up the most urgent issues, and then cut the final release (1.0?).
After that we should probably declare a quiet period and give a deadline. Only critical issues will be addressed in that timeframe, and once the deadline expires the repo would be archived (= read only, no more changes ever).
Then we import the codebase in go-hardware and carry on with the development.
This "quiet time" should probably be generous, 6 months at very least, possibly a quarter or two more.

This clean break would be backwards compatible since we won't be "moving" anything... we'd essentially be starting a new project and encouraging users to change their imports to the new location. And an approach of building something new under the github.com/go-hardware umbrella would give us an ability to work on things like the resource usage stuff in a different repo or module.

Sounds fine to me, and can't think about a less disruptive approach.
We should probably be careful for the first go-hardware release or two, to make as painless as possible for users to migrate; they will probably have the expectations about just changing the import paths, which should be honored.

Just thinking aloud, we can perhaps have some form of LTS releases in go-hardware on which we commit to backport fixes to branches for a given time (e.g. 3 months, 6 months) and declare the first go-hardware release a LTS one, for the sake of making really as smooth as possible the transition for users.

Meantime, we can plan disruptive changes (e.g. fix API rough edges, deprecating APIs...) and start implementing them after enough slack was given.

[apprehensions]

Move the repository instead of making a new one @jaypipes

https://github.com/jaypipes/ghw/transfer

[jaypipes]

@apprehensions the problem is the Go import paths... they will all change and break the world anyway.

[apprehensions]

@jaypipes Move the organization, Create a new repository with the same git commit history, but put a retract call in the go.mod. There have been some go packages that moved import paths and have done something similar AFAIK. I don't have much knowledge of this, but 100% the repository should be moved.

[jaypipes]

@apprehensions that isn't how the retract directive works or what it is used for. We're going to need users to update the go.mod files to refer to the new location in addition to updating their go code files to import the new location (or use a replace directive in their go.mod files if they don't want to go through the hassle of updating all import lines.

[apprehensions]

So, it is still possible to just move this repository to the organization?
It keeps all stars, issues, pull requests and contributors.

[jaypipes]

@apprehensions I mean, obviously we'd love to do that and be able to keep the stars, history, contributors, etc. However, that is a process that will immediately cause all existing installations of jaypipes/ghw to break because anyone doing a go mod tidy or go mod download that refers to the old github.com/jaypipes/ghw repository will be broken as the transfer is a one-direction thing that doesn't come with any automatic redirect...

[apprehensions]

https://stackoverflow.com/questions/62243083/how-to-change-go-modules-path

[ffromani]

My 2c: Suggesting the userbase to change their go.mod adding a replace is viable, but IMO is not obviously better than the approach we were evaluating. The reason is we favor the project vs we favor the users.
I'm afraid there's not yet a obviously better approach, and just to be clear, I'd also love very much to keep all the PRs, issues, contributions and history.
But if I have to choose, and unfortunately looks the case, I'd take the path which eliminate or reduce the breakage of the userbase.

[apprehensions]

Are you all sure that it is really not possible to simply add a replace directive in the project itself, update pkgsite to reflect that, and move the repository and only make new releases there? There's obviously a better way...