You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A decision was made not to support internal use cases with GoDoc. While I dislike this decision, and it was obviously not a community made one, the code could be forked and converted to support a variety of providers.
That said, I cannot find where pkg.go.dev's code resides. This development, at a minimum, should be public -- if not community involved.
To add a package or module, simply fetch it from proxy.golang.org. Documentation is generated based on Go source code downloaded from the proxy.golang.org/@.zip. New module versions are fetched from index.golang.org and added to the go.dev site every few minutes.
Athens might support some of the stuff needed to do this, but essentially there will have to be a FOSS project that follows the proprietary development being done here to remain effective for enterprises to use. That doesn't really seem a stable or scalable plan to move forward with without deep coordination.
This is what I'm requesting:
Post the code for pkg.go.dev
Post the code for GoProxy
License them appropriately so they're usable internally
Involve stakeholders in the future development of common/community tools (Stakeholders being companies using Go)
The text was updated successfully, but these errors were encountered:
A decision was made not to support internal use cases with GoDoc. While I dislike this decision, and it was obviously not a community made one, the code could be forked and converted to support a variety of providers.
That said, I cannot find where pkg.go.dev's code resides. This development, at a minimum, should be public -- if not community involved.
Even worse: https://go.dev/about
Athens might support some of the stuff needed to do this, but essentially there will have to be a FOSS project that follows the proprietary development being done here to remain effective for enterprises to use. That doesn't really seem a stable or scalable plan to move forward with without deep coordination.
This is what I'm requesting:
The text was updated successfully, but these errors were encountered: