Closed glyn closed 1 year ago
I totally sympathise!
But isn't this more an issue for the https://github.com/haskell/hackage-server ? It contains also the text for the hackage webpages.
Q: Which docs are you referring to? Can you give the link, please?
I totally sympathise! But isn't this more an issue for the https://github.com/haskell/hackage-server ? It contains also the text for the hackage webpages.
I looked there first with a view to submitting a PR, but couldn't find the web pages. I have now found them https://github.com/haskell/hackage-server/blob/b89121f8dafc371fa205735f7c58093338f09b5b/datafiles/templates/upload.html.st.
Q: Which docs are you referring to? Can you give the link, please?
The docs rooted at https://hackage.haskell.org/ such as https://hackage.haskell.org/upload.
Closing as I will raise a PR in the suggested repo. Thanks @andreasabel
Raised https://github.com/haskell/hackage-server/issues/1222 for starters.
I think it would be best practice to make any repository associated with a Hackage package public. This would help users see current issues (e.g. to avoid bothering package maintainers with dups), explore version history, etc.
For example, the sliceofpy package points to a private repository for its home page, issue tracker, and source repo. (Please note I have no complaints with this package - it was just an example I came across.)
I wonder if it would therefore be helpful to document such a best practice in the Hackage docs?
Please note I am not suggesting any kind of policy change; private repositories or tarballs with no repository would still be totally acceptable. But a docs change would gently encourage maintainers to open up their repositories.
Happy to submit a PR if appropriate (but please point me at the docs repo).