On Tue, 2010-08-03 at 09:49 -0500, Mike McGrath wrote: +1 -sv

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)

On 08/03/2010 11:18 PM, Mike McGrath wrote: Yep, `yum downgrade bodhi-server` works fine if things go south. luke

On 08/03/2010 11:20 PM, Dennis Gilmore wrote: Yep, I made the 'mandatory time-in-testing' feature configurable by release, and EPEL defaults to 14 days. luke

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/03/2010 07:49 AM, Mike McGrath wrote: While I'm not opposed to this upgrade, I wonder if I missed something. When I became aware of this bug, it only seemed to effect client side installs, that is users who had the bad build could not clone from pkgs01. But users who had a good build could, without any change to the infrastructure on pkgs01. Is there a use case failure I'm missing? - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating