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(a)lists.fedoraproject.org
[mailto:infrastructure-bounces@lists.fedoraproject.org] 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(a)gmail.com> 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