Hey guys,
I want to perform a production bodhi upgrade.
Risks are fairly minimal. I've written unit tests for the new major
features,
and have been bashing on this code in staging all day today. I also tested
`yum downgrade bodhi-server` in staging, which works fine. There are no
database schema changes.
The current version of bodhi in production slipped out of staging a week
or so ago, so a lot of these changes are already in production. This
newer release fixes a few issues, and now adheres to the
minimum-time-in-testing part of the package update acceptance criteria.
Changes in this release include:
- RSS feed & grid of unapproved critical path updates
https://admin.fedoraproject.org/updates/rss/rss2.0?critpath=True&rele...
https://admin.fedoraproject.org/updates/critpath?unapproved=True&rele...
- RSS feed & grid of user-specific comments
(
https://fedorahosted.org/bodhi/ticket/445)
https://admin.fedoraproject.org/updates/comments?user=lmacken
https://admin.fedoraproject.org/updates/rss/rss2.0?comments=True&user...
- Package-specific RSS feeds (
https://fedorahosted.org/bodhi/ticket/339)
https://admin.fedoraproject.org/updates/rss/rss2.0?package=kernel
- Add more links to the package-specific page
https://admin.fedoraproject.org/updates/TurboGears2
- Package update acceptance criteria compliance
https://fedoraproject.org/wiki/Package_update_acceptance_criteria
- Disable direct to stable pushes
(
https://fedorahosted.org/bodhi/ticket/434)
- Minimum time-in-testing requirements
- Every day bodhi will look for updates that have been in testing
for N days (default=7), and will add a comment notifying the
maintainer that the update is now able to be pushed to stable
- When someone tries to push an update to stable, bodhi will
look to
see if it has the appropriate karma, or if it has been in
testing for
more than N days.
- Critical path update changes
- Fix a bug in how we detect and track admin approvals of critpath
updates
- Hide obsolete updates in our critpath view
(
https://fedorahosted.org/bodhi/ticket/447)
- Disabled strict critical path procedures for EPEL
- EPEL is back to the same process that it has always had in bodhi
- In our nagmail job, if a critical path update is not approved,
send the
appropriate nagmail
- Bodhi command-line client fixes
- Output now goes to stdout, instead of stderr
(
https://fedorahosted.org/bodhi/ticket/449)
- Duplicate logging issue resolved
(
https://bugzilla.redhat.com/show_bug.cgi?id=613533)
- Support using --critpath and --type with --testable
- Link to the submitter and release on the home page & testing list
- Make the suggest_reboot flag actually configurable
(
https://fedorahosted.org/bodhi/ticket/352)
- Notify the security team when an update is edited and turned into a
security update (
https://fedorahosted.org/bodhi/ticket/403)
- Only verify the autokarma thresholds if it is enabled
- Only touch bugs under the Fedora/EPEL Bugzilla products
(
https://fedorahosted.org/bodhi/ticket/448)
- Prevent the masher from pushing obsolete updates
- Prevent obsolete updates from getting auto-promoted to stable
- Obsolete updates upon deletion, as opposed to destroying them.
- Added more unit tests! (up to 122)