Date: Wed, 7 Sep 2011 01:35:54 -0600 From: Chad Perrin <code@apotheon.net> To: Doug Barton <dougb@FreeBSD.org> Cc: ports@freebsd.org, jhs@berklix.com, perryh@pluto.rain.com, utisoft@gmail.com Subject: Re: sysutils/cfs Message-ID: <20110907073554.GA5414@guilt.hydra> In-Reply-To: <4E66EFC5.3020201@FreeBSD.org> References: <201109050933.p859XEbP004874@fire.js.berklix.net> <4E64C35A.50004@FreeBSD.org> <4e65b42e.M5K%2Bto11vAdk/UTk%perryh@pluto.rain.com> <4E6581E2.1060502@FreeBSD.org> <4e671817.ddHMkPbq9dJ7tLMz%perryh@pluto.rain.com> <4E66EFC5.3020201@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 06, 2011 at 09:15:01PM -0700, Doug Barton wrote: > On 09/07/2011 00:07, perryh@pluto.rain.com wrote: > >=20 > > How is it impractical to, as a rule, set an expiration date based on > > an anticipated future release date rather than only a month or two > > out from when the decision is made?=20 >=20 > As has repeatedly been explained to you, you're asking the wrong > question. The question is, how does it benefit the users to leave it in > when we know that we're going to delete it? Either way the user will > discover that the port is not easily available for installation when > they update their ports tree. >=20 > The difference is that in the meantime people doing work on the ports > tree don't have to work around the old port (that's going to be removed > anyway). The point has repeatedly been made that with almost 23,000 > ports in the tree both innovation and maintenance become significantly > more difficult. Keeping that burden as low as possible is a feature. Perhaps I have not been paying enough attention, but this is the first time I have seen this argument advanced clearly in this particular thread of discussion. I can fully understand the reasoning, now that it has been explained. (It might be obvious from this that I'm relatively new to this list.) >=20 > I realize that what you're proposing sounds attractive from a purely > theoretical standpoint. The problem is that it increases the > maintenance burden a non-trivial amount without providing any > substantive benefit. I think it might provide some benefit to users that place a premium on certain types of stability, but it probably doesn't approach offsetting the additional investment of time and effort it would require. Perhaps something could be done with little or no additional effort to help ease the process for those conservative users, probably involving some kind of notification mechanism not currently in place -- or perhaps not. I'm no expert on the management of FreeBSD's ports system. One thing I've seen come up that I definitely think would be a good idea, though, is more accessible documentation of the CVS "attic", though. I had no idea such a thing existed for old FreeBSD ports until fairly recently, and still don't know much about it. I would think that the porter's handbook, at least, should mention it (perhaps with a brief explanation of why and how one might make use of it). --=20 Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] --J/dobhs11T7y2rNN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk5nHtoACgkQ9mn/Pj01uKVN2QCfSbzP6Zy3MIohg6AWYIEBk2yA JQIAn1KqHUQo0EU/wfec8pqfBSaVTe0I =cDNZ -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110907073554.GA5414>