I'd like to use this build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2376842
on pkgs01 via the infrastructure repo to fix this problem:
http://bugzilla.redhat.com/620805
Can I get 2+1's (to sign it, add it to the repo and update it on pkgs01). It should be easy to revert if something goes wrong though I talked with tmz (a git maintainer) and he said it should be a pretty safe upgrade.
-Mike
+1
-- Matt Domsch Technology Strategist Dell | Office of the CTO
-----Original Message----- From: infrastructure-bounces@lists.fedoraproject.org [mailto:infrastructure-bounces@lists.fedoraproject.org] On Behalf Of Mike McGrath Sent: Tuesday, August 03, 2010 9:49 AM To: Infrastructure Subject: Change Request: git-1.7.2.1-2
I'd like to use this build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2376842
on pkgs01 via the infrastructure repo to fix this problem:
http://bugzilla.redhat.com/620805
Can I get 2+1's (to sign it, add it to the repo and update it on pkgs01). It should be easy to revert if something goes wrong though I talked with tmz (a git maintainer) and he said it should be a pretty safe upgrade.
-Mike
_______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Tue, 2010-08-03 at 09:49 -0500, Mike McGrath wrote:
I'd like to use this build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2376842
on pkgs01 via the infrastructure repo to fix this problem:
http://bugzilla.redhat.com/620805
Can I get 2+1's (to sign it, add it to the repo and update it on pkgs01). It should be easy to revert if something goes wrong though I talked with tmz (a git maintainer) and he said it should be a pretty safe upgrade.
+1 -sv
On Tuesday, August 03, 2010 09:49:22 am Mike McGrath wrote:
I'd like to use this build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2376842
on pkgs01 via the infrastructure repo to fix this problem:
http://bugzilla.redhat.com/620805
Can I get 2+1's (to sign it, add it to the repo and update it on pkgs01). It should be easy to revert if something goes wrong though I talked with tmz (a git maintainer) and he said it should be a pretty safe upgrade.
+1
Ill get it signed and pushed now
Dennis
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...
https://admin.fedoraproject.org/updates/critpath?unapproved=True&release... - 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=lm... - 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 Tue, 3 Aug 2010, Luke Macken wrote:
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:
+1, I assume if things go south we can just downgrade right?
-Mike
On 08/03/2010 11:18 PM, Mike McGrath wrote:
On Tue, 3 Aug 2010, Luke Macken wrote:
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:
+1, I assume if things go south we can just downgrade right?
Yep, `yum downgrade bodhi-server` works fine if things go south.
luke
On Tuesday, August 03, 2010 05:59:08 pm Luke Macken wrote:
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...
3
https://admin.fedoraproject.org/updates/critpath?unapproved=True&release...
3 - 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=lm...
en - 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 EPEL requires 14 days, can we default to that for EPEL
Dennis
On 08/03/2010 11:20 PM, Dennis Gilmore wrote:
On Tuesday, August 03, 2010 05:59:08 pm Luke Macken wrote:
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...
3
https://admin.fedoraproject.org/updates/critpath?unapproved=True&release...
3 - 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=lm...
en - 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-testingrequirements
- Every day bodhi will look for updates that havebeen in testing
for N days (default=7), and will add a commentnotifying the
maintainer that the update is now able to be pushedto stable EPEL requires 14 days, can we default to that for EPEL
Yep, I made the 'mandatory time-in-testing' feature configurable by release, and EPEL defaults to 14 days.
luke
On Wednesday, August 04, 2010 07:53:47 am Luke Macken wrote:
On 08/03/2010
11:20 PM, Dennis Gilmore wrote:
On Tuesday, August 03, 2010 05:59:08 pm
Luke Macken wrote:
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...
F1
3
https://admin.fedoraproject.org/updates/critpath?unapproved=True&release...
F1
3 - 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=lm...
ck
en - 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 pushedto
stable
EPEL requires 14 days, can we default to that for EPEL
Yep,
I made the 'mandatory time-in-testing' feature configurable by
release,
and EPEL defaults to 14 days.
luke
_______________________________________________
infrastructure mailing
list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure +1 then
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/03/2010 07:49 AM, Mike McGrath wrote:
I'd like to use this build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2376842
on pkgs01 via the infrastructure repo to fix this problem:
http://bugzilla.redhat.com/620805
Can I get 2+1's (to sign it, add it to the repo and update it on pkgs01). It should be easy to revert if something goes wrong though I talked with tmz (a git maintainer) and he said it should be a pretty safe upgrade.
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
On Fri, 6 Aug 2010, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/03/2010 07:49 AM, Mike McGrath wrote:
I'd like to use this build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2376842
on pkgs01 via the infrastructure repo to fix this problem:
http://bugzilla.redhat.com/620805
Can I get 2+1's (to sign it, add it to the repo and update it on pkgs01). It should be easy to revert if something goes wrong though I talked with tmz (a git maintainer) and he said it should be a pretty safe upgrade.
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?
I think you're right actually, tmz and I discussed on #fedora-admin and realized after we upgraded it that it didn't much make a difference on the server.
-Mike
infrastructure@lists.fedoraproject.org
-
Dennis Gilmore -
Jesse Keating -
Luke Macken -
Matt Domsch -
Mike McGrath -
Seth Vidal