boostorg/website-v2

Outcome issues tracker link is incorrect

Opened this issue · 5 comments

vinniefalco commented

That's an annoying special case... is this really what we want? What if every Boost library did this, it would make filing issues quite irritating.

ned14 commented

Outcome's users don't seem to mind one way or another. They want support, wherever provides it works for them.

d-spencer-strickland commented

Wonder what those commits per month are coming from then.

@williln How are we creating that GitHub link? Is it assuming the structure of the URL based on the library name? If so, do we have access to get to atypical github URLs like this? Thanks!

williln commented

@4down the link to the library issues is generated from the Library.github_url (we weren't aware of exceptions at the time). https://github.com/boostorg/website-v2/blob/0.0.520/libraries/models.py#L260

The github_url comes from the GitHub API repo response when we create/update the libraries: https://github.com/boostorg/website-v2/blob/0.0.520/libraries/github.py#L82

Because it's a property generated based on another field, and not its own field, we can't override it in the admin. There are a couple ways this could be handled though.

Option 1: Follow a similar process to the one we use for library-version docs URL exceptions:

  1. Create a new constant in libraries/constants.py with whatever the exceptions are (a dictionary with the library slug as the key, and the replacement github issues URL as the key)
  2. Edit Library.github_issues_url to check that constant before it checks the repo field

This lets you retain the main GitHub URL but link to a separate issues tracker that might not even be on GitHub at all. But the issues url would still not be editable in the admin.

Option 2: Use the constants exceptions process, but create github_issues_url as a database field instead

  1. Create a new constant in libraries/constants.py with whatever the exceptions are (a dictionary with the library slug as the key, and the replacement github issues URL as the key)
  2. Add a field github_issues_url to the Library model and remove the property
  3. Check the constants dictionary for exceptions to the github_issues_url so you can load replacement URLs, otherwise generate the issues URL using the github_url
    https://github.com/boostorg/website-v2/blob/0.0.520/libraries/github.py#L84

This is more overhead, but it makes the field editable in the admin, which may be convenient later on.

For this library, the "commits per month" are coming from the "Boost" version of the repo: https://github.com/boostorg/outcome/

Let me know if you need any more info or help!

vinniefalco commented

Perhaps we can use the GitHub API to detect when Issues are disabled on the repo. Another possibility is to check if the boostorg repo is the "source" or just a fork. But we probably will need a "manual override" field for special snowflakes who insist on keeping the issues elsewhere. Niall is in good company here, as Christopher Kohlhoff (asio author) also employs this practice. Except that Chris doesn't bother to disable issues in the Boost repository.