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@xxxxxxxxxx> 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. > Its all those little things that people don't think about that I worries > me. What's the benefit of keeping them around? I mean, I can commit > to saying "we'll remove a project and keep it offline for a year if someone > complains we'll give it to them". The benefit of keeping them around is the same as the benefit for why we don't prune historical src.rpms or tarballs from distcvs. Or why we don't prune the history of source repos in general. Yes, it may be ancient history, but it's still history. And there's a lot that can be learned from history. Just ask the people that have done things like importing _all_ kernel history since the dawn of time (that at least they can find tarballs for). Or ajax and his "X since the dawn of time" archive. > I guess I'm just putting my foot down on this since almost all the support > for "keep everything around forever" has come from people that don't have > to deal with the consequences of that decision. This isn't a file being > kept on someones desktop... You're right, it's not a file that's being kept on someone's desktop. It's something far more important -- it's the DNA of the evolution of open source. Jeremy _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
