Community should fork this project and maintain it on its own.

[prochac]

@mitchellh doesn't have time to maintain this project and plans to archive it.

#172

#328 (comment)

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

[mitchellh]

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.

[sagikazarmark]

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!

[mitchellh]

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.

❤️

[sagikazarmark]

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.

[sagikazarmark]

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

[mitchellh]

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

[sagikazarmark]

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

[prochac]

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

[mitchellh]

All good, thanks to both you 😄

[prochac]

But is open source, anybody can be sleeping russian agent

[mitchellh]

I hid your comment, I don't want to offend anyone right now as we're just about to archive this project 😄

[sagikazarmark]

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