Change Request: bodhi-0.7.7

[Luke Macken]

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&release=F13
 
https://admin.fedoraproject.org/updates/critpath?unapproved=True&release=F13
- 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=lmacken
- 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)