Git Product home page Git Product logo

Comments (10)

ffromani avatar ffromani commented on June 20, 2024 1

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.

apprehensions avatar apprehensions commented on June 20, 2024

Move the repository instead of making a new one @jaypipes

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

from ghw.

jaypipes avatar jaypipes commented on June 20, 2024

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

from ghw.

apprehensions avatar apprehensions commented on June 20, 2024

@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.

jaypipes avatar jaypipes commented on June 20, 2024

@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.

apprehensions avatar apprehensions commented on June 20, 2024

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

from ghw.

jaypipes avatar jaypipes commented on June 20, 2024

@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.

apprehensions avatar apprehensions commented on June 20, 2024

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

from ghw.

ffromani avatar ffromani commented on June 20, 2024

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.

apprehensions avatar apprehensions commented on June 20, 2024

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)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.