ffromani
commented
7 months ago 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
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