Date: Wed, 11 Jun 2003 15:21:58 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Doug Barton <DougB@freebsd.org> Cc: arch@freebsd.org Subject: Re: removing stale files Message-ID: <20030611222158.GB870@athlon.pn.xcllnt.net> In-Reply-To: <20030611144115.E26376@12-234-22-23.pyvrag.nggov.pbz> References: <20030610124747.A7560@phantom.cris.net> <20030610024524.D23396@znfgre.qbhto.arg> <20030611075750.GB57496@wantadilla.lemis.com> <20030611.093203.26943899.imp@bsdimp.com> <p05210613bb0d2187f0dd@[128.113.24.47]> <20030611190615.GA15695@dhcp01.pn.xcllnt.net> <p05210614bb0d30155a2e@[128.113.24.47]> <20030611210632.GA695@athlon.pn.xcllnt.net> <20030611144115.E26376@12-234-22-23.pyvrag.nggov.pbz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 11, 2003 at 02:49:02PM -0700, Doug Barton wrote: > > > > This very much surprises me, because I don't see how you can > > mess up if you stick to the fundamentals. Do I have a huge > > blind spot? > > Not a blind spot necessarily, but perhaps you haven't had a lot of > experience with the infinite "creativity" of our users. Yes, I have and that's why I don't make it my responsibility. No matter how hard we try to keep all the infinite creativity into account, there's always someone with a mind more perverted than we think would be possible. There's no way we can make it fool proof. So why bother? Keep it simple and fundamental and adjust according to feedback. The more perfect our initial implementation the better, but when dealing with a lot of unknowns and uncertainties, any start is a good one. Example: if we get a lot of negative feedback that removing stale files (unconditionally) causes more problems than is acceptable, you can opt to do a md5 checksum and only remove stale files if the checksum matches. We do that with ports and it must work well enough considering the number of problem reports... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030611222158.GB870>