- Add basic line change counts for each x.x.0 library versions.
- import line change counts during `import_commits` task.
- Add `update_issues` management command for importing Issues for each
LibraryVersion.
- Add update issues runnable command in `Issue` admin.
- Build word cloud using mailinglist content.
- Update release report with new data.
View stats per release, we do this by
doing log diffs between release tags. Ex: `git log
boost-1.78.0..boost-1.79.0`. The output is parsed and the commits
are saved with a foreign key to the `LibraryVersion` it relates to.
- commits are imported by doing "bare" clones (no project files, only
git data) of repos into temporary directories, as created by python's
bulitin `tempfile.TemporaryDirectory`
- Added Commit model
- Added CommitAuthor model
- Added CommitAuthorEmail model
- One CommitAuthor can have many emails.
- Added task for importing commits. (and admin link to trigger it)
- Added task for importing CommitAuthor github data (avatar and profile
url, with admin link to trigger it)
- Added a basic Library stat page which can be viewed by going to the
admin -> library -> view stats.
- Added a `Get Release Report` button in the `LibraryAdmin` which allows
a staff member to select a boost version and up to 8 libraries to
generate a report for. The report is just a webpage which attempts to
convert cleanly to a pdf using the browser's print to pdf functionality.
- Updated the Library Detail page to show commits per release instead of
per month.
- Updated the Library Detail page to show `Maintainers & Contributors`
sorted by maintainers, then the top contributors for the selected
release, then the top contributors overall by commits descending.
- Removed CommitData, which was tracking monthly commit stats
- Add `verbose` flag to `import_versions` to allow user to silence the output
- Removed some unused options from `import_versions`
- Moved the exclusion logic in `import_versions` to its own function
- Stop getting the `github_url` from the github API. Instead, generate it from the tag. (reason: in older tags, the best URL GitHub gives us is a less-useful one to a _commit_ and not a tag. We can generate the url, though.)
- Move the retrieval of the `release_date` to its own task, so it can be loaded async. (reason: it's a separate API call per version to get the date)
- Make `release_date` optional on the `Version` model (reason: make the field easier to load async)
- Simplify logic to retrieve `release_date` and just always retrieve it from the commit
- Stop loading the version `description` from GitHub. We don't use it on the frontend anyway, and in all but the most recent couple of versions, the `description` is the comment from the commit, which is usually not useful.
