All the copies of mirrormanager can get nuked directly. Dennis beat on me for throwing them in there rather than wait for them to propagate to epel-testing when I wanted them... -- Matt Domsch Technology Strategist Dell | Office of the CTO -----Original Message----- From: infrastructure-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:infrastructure-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Kevin Fenzi Sent: Wednesday, April 13, 2011 2:35 PM To: Fedora Infrastructure Subject: Re: Infrastructure repo On Wed, 13 Apr 2011 12:14:37 -0700 Toshio Kuratomi <a.badger@xxxxxxxxx> wrote: > We can probably age out and discard those SRPMS as well... I do try to > clean out old releases for fas and pkgdb, for instance. I was thinking more for the historical record if we needed it. Ie, someone needs to know what fas version we used at time X and what was in that package. If we have the srpm and timestamp we could examine it. In practice I doubt it would come up much, especially if those packages don't have any local patches, just newer versions... > I do tend to keep at least one older version around -- I suppose that > we could just do that in the SRPM repo and only keep newest in the RPM > repo... although the primary reason to keep older packages is to be > able to revert within the first week or so of a new release in case > something is wrong with an update. Quick reversion means having the > last binary packages stick around. Yeah. Keeping one old one around seems reasonable. > > * Once per cycle we clean out the i386/x86_64 packages that are no > > longer installed on any machine. > > > +1 > > > (As a side note, I am thinking we should setup a Housekeeping SOP > > for once per cycle a few weeks after release... we can then do this, > > prune people who don't need to be in sysadmin groups anymore, prune > > hosted projects or lists, etc. Of course thats another topic). > > Also +1. Draft here: https://fedoraproject.org/wiki/Infrastructure_post_release_housekeeping will clean up and try and get it to the point of discussing. ;) kevin _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
