Skip to content

Instantly share code, notes, and snippets.

@mitchellh

mitchellh/archive.md

Last active January 17, 2024 11:17
Show Gist options
  • Star 24 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mitchellh/90029601268e59a29e64e55bab1c5bdc to your computer and use it in GitHub Desktop.
Save mitchellh/90029601268e59a29e64e55bab1c5bdc to your computer and use it in GitHub Desktop.
Download ZIP
Archive List
Raw
archive.md

Planned Repo Archive

In the new year, I plan on archiving the repositories below. Because I plan on only archiving the repositories, any project that depends on any of these projects will continue to work. However, I will no longer be accepting issues or pull requests and will never tag a new release.

The reality of each of the projects listed below is that I've almost completely ignored issues and pull requests for a couple years. Archiving the project is more about sending the right message about the status of the project more than any practical impact since almost all haven't been maintained recently anyways. I'm sorry about not being transparent about this earlier.

Admittedly, this is something I should've done long ago, but the reason why I am doing this now is a combination of multiple factors. One, all of the projects below are Go libraries, and I am now very rarely writing Go. Second, I am no longer actively working on any projects that consume these libraries, so my motivation to keep them up to date is gone. Third, I don't have the personal time to keep up with this many libraries anymore. And fourth, I'm trying to free up more obligations so I can healthily work on new things.

To repeat: Existing dependent projects will continue to work. I only plan on archiving the projects below, I'm not deleting them. So existing projects that depend on these repositories will continue to function as before. And like I said, given I've poorly maintained them for a couple years already, there is already little practical difference in this decision (i.e. I've closed few if any issues/PRs), I'm just trying to be more transparent and intentional moving forward.

The List

(All under "mitchellh" on GitHub)

If you're interested in continuing any of these projects, please fork the project. If you're an active user of one of these projects and have a history I can point to to build trust, I'd be happy to mark your fork as blessed.

@mfridman
Copy link

Thanks for the transparency, this answers my question w.r.t mitchellh/protoc-gen-go-json#17 (comment).

I presume you're not interested in adding collaborators/maintainers on the repositories themselves?

Given this, I'll probably fork since it's very much in my current wheelhouse and a few users have been asking about this plugin.

@mitchellh
Copy link
Author

I presume you're not interested in adding collaborators/maintainers on the repositories themselves?

I'd rather not, because I don't want to send the message under my namespace "mitchellh" that it's being maintained. I'd prefer the ownership be clear. If you're interested in taking this on, you've been consistent in contributing to this project in the past and I'd be happy to bless that direction!

@bep
Copy link

bep commented Dec 20, 2023

Ref. the "blessed fork" of mapstructure

@mfridman
Copy link

mfridman commented Dec 20, 2023 •
edited

I presume you're not interested in adding collaborators/maintainers on the repositories themselves?

I'd rather not, because I don't want to send the message under my namespace "mitchellh" that it's being maintained.

Makes perfect sense. There's a satisfying feeling of archiving a Github project and eliminating the overhead (which includes maintaining collaborators, etc.).

Given I still use this plugin and it's fairly popular in the community, I'll fork it and go from there. (ps. our paths crossed a few times in Go projects, 'till next time in a different ecosystem 🌊)

https://github.com/mfridman/protoc-gen-go-json

@tuananh
Copy link

tuananh commented Dec 20, 2023

Ref. the "blessed fork" of mapstructure

* https://github.com/go-viper is a org with no (1?) member and only one project (mapstructure).

* This is not the same as @spf13 's https://github.com/spf13/viper project (which I assume is the "well-maintained, well-known Go project" you refer to).

i made the mistake assuming it's related to https://github.com/spf13/viper too

@jamietanna
Copy link

i made the mistake assuming it's related to https://github.com/spf13/viper too

+1 on the fact that it does seem a little confusing - but as per mitchellh/mapstructure#349 (comment) this appears to be intended. The author is a regular committer to viper and it looks like it is a reasonable request + move

@bep
Copy link

bep commented Dec 20, 2023

@jamietanna I'm also a long time committer to Viper, and I have not seen a discussion about moving the repo into an org (I did a search now). This is in the end all fine and dandy, I'm sure, but the "blessed fork" labels should be not added without any inspection; I was about to blindly do a "search and replace" of the mapstructure imports based on the above premise.

@mitchellh
Copy link
Author

mitchellh commented Dec 20, 2023 •
edited

I removed that link for now. I’ll do a bit more diligence on that and then readd later if it makes sense. I'm pretty sure that's where the Viper projects are going to be transferred to eventually and the maintainer is the also the maintainer of Viper, but I asked for clarification and will re-add that link once I receive it.

EDIT: After the response and the contribution history, I believe the mapstructure fork has enough background for me to call it trusted. I don't know the maintainer personally but there's enough social evidence for me to trust the intentions.

@sagikazarmark
Copy link

I've been the sole active maintainer of Viper for some years now.

Viper itself will not move, but some of the components will be extracted to external repos. Instead of creating those repos under spf13 they will be moved under the go-viper organization.

I started documenting these decisions here: https://github.com/spf13/viper/pull/1171/files#diff-b7f53412bda09913026d36de226a3b27ea70c5dd598889cab3a5800c880a17a9

Hope that clarifies things a bit.

@bep both Steve and I are members of that organization. I know you are a committer in Viper, so I'm happy to add you there as well.

Also, I'm happy to invite individual contributors to the fork who are willing to help with maintenance.

@dereknola
Copy link

I'm seeing that github.com/mitchellh/osext repo has been deleted. Unfortunately, this repo is still in active use across several large repos, most notably github.com/Microsoft/hcsshim. Is it possible to restore and archive that repo?

The fun hell of go dependency chains:

go: github.com/Microsoft/hcsshim@v0.11.4 requires
	github.com/open-policy-agent/opa@v0.42.2 requires
	oras.land/oras-go@v1.2.0 requires
	github.com/distribution/distribution/v3@v3.0.0-20221208165359-362910506bc2 requires
	github.com/mitchellh/osext@v0.0.0-20151018003038-5e2d6d41470f: invalid version: git ls-remote -q origin in /home/derek/go/pkg/mod/cache/vcs/94ed57c5b21c953d93b47487113db43a5c9b69fd990329ec70dc77348c4dd443: exit status 128:
	remote: Repository not found.
	fatal: repository 'https://github.com/mitchellh/osext/' not found

For what its worth, I have opened an issue with them to move to a much newer version of open-policy-agent

@mitchellh
Copy link
Author

mitchellh commented Dec 20, 2023 •
edited

I'm seeing that github.com/mitchellh/osext repo has been deleted. Is it possible to restore and archive that repo?

No, sorry. I don’t have access to the source code at all anymore. Even if I did, that repository had a bolded warning in the readme for around 6 years or something like that asking people to not use the project and move on to using the Go stdlib or some other option (the functionality most was moved into the Go stdlib). I think 6 years is long enough to warn users. Sorry about that.

@dereknola
Copy link

Hey no problem, I understand people ignoring warning about deprecation.

@cfabianski
Copy link

cfabianski commented Dec 21, 2023 •
edited

Not in the list but Gon could maybe be included? http://github.com/Bearer/gon
Bearer/gon#7

[EDIT] Goreleaser's maintainer will be waiting for the blessing goreleaser/goreleaser#4493 (comment)

@guettli
Copy link

guettli commented Jan 5, 2024

Maybe it makes sense to create something like Python Jazzband?

@thaJeztah
Copy link

thaJeztah commented Jan 9, 2024 •
edited

@dereknola I'm a bit confused where that dependency comes from in your example; looking at hcsshim v0.11.4, there's no dependency on https://github.com/distribution/distribution/v3 (only on github.com/docker/distribution v2.8.1+incompatible); https://github.com/microsoft/hcsshim/blob/v0.11.4/go.mod#L50C14-L50C20

Ah, I guess it finds some transitive path in oras; when trying the hcsshim repository;

git checkout v0.11.4

go mod graph | grep ' github.com/distribution/distribution/v3'
oras.land/oras-go@v1.2.0 github.com/distribution/distribution/v3@v3.0.0-20220526142353-ffbd94cbe269

go mod graph | grep ' oras.land/oras-go'
github.com/open-policy-agent/opa@v0.42.2 oras.land/oras-go@v1.2.0

go mod graph | grep ' github.com/open-policy-agent/opa'
github.com/Microsoft/hcsshim github.com/open-policy-agent/opa@v0.42.2

oras v1.2.0 indeed depends on distribution/distribution (but some other commit (ffbd94cbe269)); https://github.com/oras-project/oras-go/blob/v1.2.0/go.mod#L7

But not sure why it would look at that, given that the repository already has depencencies resolved (which doesn't include that version);

git grep distribution/distribution
go.sum:github.com/distribution/distribution/v3 v3.0.0-20220526142353-ffbd94cbe269/go.mod h1:28YO/VJk9/64+sTGNuYaBjWxrXTPrj0C0XmgTIOjxX4=
test/go.sum:github.com/distribution/distribution/v3 v3.0.0-20220526142353-ffbd94cbe269/go.mod h1:28YO/VJk9/64+sTGNuYaBjWxrXTPrj0C0XmgTIOjxX4=
vendor/github.com/google/go-containerregistry/pkg/v1/remote/transport/error.go: // https://github.com/distribution/distribution/blob/6a977a5a754baa213041443f841705888107362a/registry/api/errcode/register.go#L60

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment