Comments (10)
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.
from ghw.
Move the repository instead of making a new one @jaypipes
https://github.com/jaypipes/ghw/transfer
from ghw.
@apprehensions the problem is the Go import paths... they will all change and break the world anyway.
from ghw.
@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.
from ghw.
@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.
from ghw.
So, it is still possible to just move this repository to the organization?
It keeps all stars, issues, pull requests and contributors.
from ghw.
@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...
from ghw.
https://stackoverflow.com/questions/62243083/how-to-change-go-modules-path
from ghw.
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.
from ghw.
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...
from ghw.
Related Issues (20)
- drop use of blkid on block_linux.go HOT 1
- implement PCI module on Windows HOT 6
- github.com/StackExchange/wmi is archived, change it HOT 1
- too many open files error when using ghw in gotop client HOT 1
- Panic when collecting host information HOT 5
- Consider updating declared Go version in go.mod HOT 1
- On my windows, sometimes it show error: Cannot change thread mode after it is set HOT 7
- ci: enable gh actions with arm64 HOT 1
- ARM: failed to determine memory area for node: open /sys/devices/system/memory/block_size_bytes: no such file or directory HOT 7
- HDD is classified as SSD on windows 10 HOT 1
- Linux: failed to determine memory area for node: open /sys/devices/system/node/node0/memory_failure/state: no such file or directory HOT 13
- Possible bug in parsing core.ID and core.Index HOT 10
- change library to github.com/yusufpapurcu/wmi HOT 2
- Support querying current resource usage HOT 1
- FreeBSD/Darwin GPU support HOT 1
- Retrieval of core_id and physical_package_id for CPUs that are offline.
- Expose CPU flags HOT 2
- bonded network interfaces result in missing MAC address for NIC HOT 2
- Retrieve SCSI_IDENT_SERIAL info on block device HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ghw.