Removal of old projects from fedorahosted.

[Mike McGrath]

On Tue, 9 Sep 2008, Jeremy Katz wrote:

> On Tue, 2008-09-09 at 21:33 -0500, Mike McGrath wrote:
> > On Wed, 10 Sep 2008, Paul W. Frields wrote:
> > > On Tue, 2008-09-09 at 21:02 -0500, Mike McGrath wrote:
> > > > On Tue, 9 Sep 2008, Robin Norwood wrote:
> > > >
> > > > > On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath <mmcgrath at redhat.com> wrote:
> > > > > > Nope, the terms of use are already pretty clear.  And no one has provided
> > > > > > a compelling reason to keep these projects around, just lots of
> > > > > > suggestions on how to keep them around.  Deleted is what we want, not
> > > > > > delisted or saved forever or anything like that.  We're not going to
> > > > > > commit any resources to a project that choosed not to use this free
> > > > > > service.
> > > > >
> > > > > Well, because sooner or later, you'll delete a project that someone
> > > > > didn't want deleted, and they'll be ticked off.  Maybe they'll open a
> > > > > ticket and convince the infra. team to restore the data from a backup,
> > > > > or maybe they'll just be ticked off and rant about how much Fedora
> > > > > sucks for deleting this thing they didn't want deleted.
> > > > >
> > > >
> > > > I'm fine with that.  Its well documented.  and its not like we're going to
> > > > rm -rf the thing.  We'll keep it around for a while but no promises.
> > > >
> > > > > Again, I'm assuming the per-project maintenence cost is near zero (ie,
> > > > > a little bit of disk space).  If not, then maybe I could see a case
> > > > > for automatically deleting old projects.
> > > > >
> > > >
> > > > Ah, thats an incorrect assumption.
> > >
> > > Is there a way to balance deactivating the greater project needs with
> > > the value of the source code as a useful historical artifact?  In other
> > > words, if we reduced (for example) an active git-based project to just
> > > the .git stuff, and made it available for download only, then the cost
> > > really is just disk space, right?
> > >
> >
> > Nope not just disk space.
> >
> > > I wouldn't want to see Infrastructure roped into committing lots of
> > > resources to carry a ton of dead projects.  If there's a significant
> > > per-project maintenance cost, even if it just adds up to something
> > > significant over hundreds of projects, the work has to be justified
> > > somehow.  Is there a way to keep the source around but not induce the
> > > maintenance cost?  Am I being naive about this?
> > >
> >
> > Backups, time to maintain, bandwidth for the backups, testing when we make
> > changes, people to notify should our Infrastructure get compromised again,
> > etc, the unknown.
>
> Backups really are equivalent to disk space.  Testing for changes --
> maybe.  But if it's really that inactive, then a change is unlikely to
> break it.  And if it does, then when someone notices, they'll holler.
>
> As for the people to notify bit, I liked Nigel's idea of delist
> +read-only -- then you don't have to worry about notifying, but at the
> same time, it's easy to have access restored if it becomes relevant.
>

So it seems I'm alone here, if we have to keep everything forever, thats
what it'll be.  I'll just have to see to it we have the resources and
backup materials in the future when that time comes.  I have a question
and a suggestion for people.

1) What do we do with projects to which no owner or responsible party can
be found?  This caused major headaches during the elvis move...  headaches
we still have today.  What would you have us do?



2) Right before we start removing projects is _not_ the time to discuss
the policy.  When the policy is put in place... thats the time to discuss
it.

	-Mike