Date: Tue, 06 Sep 2011 21:15:01 -0700 From: Doug Barton <dougb@FreeBSD.org> To: perryh@pluto.rain.com Cc: ports@freebsd.org, jhs@berklix.com, utisoft@gmail.com Subject: Re: sysutils/cfs Message-ID: <4E66EFC5.3020201@FreeBSD.org> In-Reply-To: <4e671817.ddHMkPbq9dJ7tLMz%perryh@pluto.rain.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/07/2011 00:07, perryh@pluto.rain.com wrote: > Doug Barton <dougb@freebsd.org> wrote: > >>>>>>> Better to deprecate such non urgent ports, & wait a while >>>>>>> after next release is rolled, to give release users a warning >>>>>>> & some time to volunteer ... >>>> >>>> That's an interesting idea, but incredibly unlikely to happen. >>> >>> It _certainly_ won't happen if those in charge refuse to try it! >> >> My point was that the idea is impractical. I was trying to be polite. > > 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? 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. 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. To answer your question more directly, start thinking through all the possible permutations of having 4 completely separate branches of FreeBSD active and supported at the same time, with releases happening several times a year. Now consider how to handle EOL branches. Then consider that FreeBSD has _never_ supported a release-branched ports tree, precisely because it's a huge amount of additional work that we don't have person-hours for. 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. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E66EFC5.3020201>