Community should fork this project and maintain it on its own.
prochac opened this issue · 21 comments
@mitchellh doesn't have time to maintain this project and plans to archive it.
@sagikazarmark (Viper contributor, https://github.com/spf13/viper/graphs/contributors) shows interest to create fork under an umbrella of Viper project.
This issue was created mostly for better visibility and communication than in the linked PR.
Hi! Yes, I’m sorry for “breaking the news” in the comment. I always planned (and still do) to make a list of repositories I no longer wish to maintain and asking the community for a fork before archiving them. I wasn’t going to suddenly archive this repo, I just was responding to your issue since you asked. I think in practice its not a big difference since I’m very poorly/barely maintaining it now, anyways…
@sagikazarmark Extremely supportive of forking this under Viper. Viper is a great project. I’d be happy to update the README and support that as the official, I think that project has shown good OSS stewardship.
And I also agree with the linked comments that a fork is the best option, rather than a transfer.
Thank you @prochac for opening this issue.
@mitchellh I forked the project under go-viper (https://github.com/go-viper/mapstructure). (There isn't much in there yet, but that's where Viper subprojects will gravitate eventually)
Thank you for all the work you've put into this project (well...all of them). I wish you all the best in your next endeavor!
Thank you very much. I'll leave the project unarchived for now and let you handle migrating any issues or PRs you want. Then at some future point I'll update the README to point to the Viper project and archive.
❤️
Thank you @mitchellh !
I started pulling in some of the more serious bug fixes into the fork.
I'll tag 1.6.0 soon with the current module name and then tag a v2 renaming the module, so the fixes can still be used as a drop-in replacement.
I also plan to send a message to all pending issues and PRs asking them to resubmit in the new repo, so that we can do some cleanup around stale issues/PRs.
Tagged a new version with the old import path: https://github.com/go-viper/mapstructure/releases/tag/v1.6.0
Also started to work on v2 with the new import path: https://github.com/go-viper/mapstructure/releases/tag/v2.0.0-alpha.1
@sagikazarmark I mistakenly thought the go-viper org and Viper project in reference this whole time was the official spf13/viper project. I can see you're the top contributor to spf13/viper, and I assume maintainer but not 100% sure. Can you make it clear what your association is and what the go-viper org is? (I'm still thankful for your fork and work here and I'm not accusing you of anything untoward, just want to make sure this is totally clarified)
@mitchellh no worries!
Yes, I'm a maintainer of Viper (spf13/viper) and the go-viper organization is associated with that project. The long-term plan is to move some of the remote providers and encoding plugins to external repos to reduce the number of dependencies in the core Viper project.
The core repository will remain under @spf13's personal account to avoid breaking the thousands of imports. :)
Hope that clarifies things a bit.
@mitchellh that's why I added the link to viper contributors. https://github.com/spf13/viper/graphs/contributors
To add @sagikazarmark some credibility.
He seems legit.
All good, thanks to both you 😄
But is open source, anybody can be sleeping russian agent
I hid your comment, I don't want to offend anyone right now as we're just about to archive this project 😄
@mitchellh are you OK with me sending a message to all open issues and PRs that they may resubmit to the fork?
I pulled in the PRs the seemed to have fixed the most inportant issues, but there are quite a few other valuable contributions there.
Yes I’m okay with that, thanks for asking
Curious if transferring the repository is an option, so that GitHub's redirects lead visitors to the right place, preserve more history such as tickets and pull requests, and go modules to function without "replace" rules for versions of the module before renaming.
I see the other repository is now "ahead" a couple of commits, but the module hasn't been renamed yet, so that may complicate things a bit (this repository's git would probably have to be aligned before that)
I see the other repository is now "ahead" a couple of commits, but the module hasn't been renamed yet
Ignore me 🙈 I looked at the v1.6.0 tag, which carries the old name, but it was renamed since
@thaJeztah no worries, your question prompted me to add a migration guide to the README.
Any guidance on which repo to open issues into?
@EronWright https://github.com/go-viper/mapstructure is the blessed fork, so I'd suggest opening new issues there.
If the change is official, can you add a notice to the README, and maybe archive this repository? The current state of affairs is a bit confusing tbh
I tagged 2.0.0: https://github.com/go-viper/mapstructure/releases/tag/v2.0.0
@mitchellh I can open a PR to add a notice to the readme if you want me to, but it may be better if it comes from you. Let me know which one you prefer.