From owner-freebsd-ports@FreeBSD.ORG Wed Sep 7 10:24:57 2011 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98ABE106564A; Wed, 7 Sep 2011 10:24:57 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 7AF218FC1B; Wed, 7 Sep 2011 10:24:57 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p87AOmFh046417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Sep 2011 03:24:49 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p87AOmcQ046416; Wed, 7 Sep 2011 03:24:48 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA29334; Wed, 7 Sep 11 03:02:54 PDT Date: Wed, 07 Sep 2011 10:02:42 -0700 From: perryh@pluto.rain.com To: dougb@freebsd.org Message-Id: <4e67a3b2.CVKcpQ8KQzuo8BP+%perryh@pluto.rain.com> References: <201109050933.p859XEbP004874@fire.js.berklix.net> <4E64C35A.50004@FreeBSD.org> <4e65b42e.M5K+to11vAdk/UTk%perryh@pluto.rain.com> <4E6581E2.1060502@FreeBSD.org> <4e671817.ddHMkPbq9dJ7tLMz%perryh@pluto.rain.com> <4E66EFC5.3020201@FreeBSD.org> In-Reply-To: <4E66EFC5.3020201@FreeBSD.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, jhs@berklix.com, utisoft@gmail.com Subject: Re: sysutils/cfs X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 10:24:57 -0000 Doug Barton wrote: > On 09/07/2011 00:07, perryh@pluto.rain.com wrote: > > Doug Barton 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 ... > > > > 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 ... I think you may have gotten me confused with someone else. > 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. Reread the first paragraph. Provided the port is still in the tree, when they try to build it the ports mechanism reports the FORBIDDEN/BROKEN/whatever which describes the problem, and the expiration date a month or two out. (If the expiration date is not included in the report, it should be.) They then know that they need to fix the port, or find someone to fix it, and they know _why_ it needs to be fixed. In contrast, if the port is _no longer_ in the tree, they have no clue why it disappeared. > 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). It's only going to be removed if no one fixes it. The whole point is that "release users" don't continuously monitor their ports -- they only upgrade when they become aware that they need to (e.g. when a newer release becomes available). The proposal is to increase the liklihood that, come upgrade time, a "release user" gets a specific, actionable description of any problems that have arisen, rather than having a port that they have been using mysteriously disappear. > 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. s/point/claim/ Last I checked, freebsd.org was claiming that the very large number of supported ports was a feature. It seems that some of the ports committers disagree. > 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. So define a variable along the lines of NEXT_PORT_PURGE_DATE in one of the /usr/share/mk/bsd.port*.mk files, which (being part of the base) _are_ branched, and when a situation of the kind under discussion arises set the port's EXPIRATION_DATE to NEXT_PORT_PURGE_DATE. (And before you start jumping all over the details, I recognize that this is a rough first cut at a mechanism that would need some details fleshed out.) > Now consider how to handle EOL branches. Last I heard, the ports tree does not claim to support EOL branches. Why does this proposal need to? > 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. How does this proposal require a release-branched ports tree? > 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. Benefit: see above. Maintenance: I would not think that updating NEXT_PORT_PURGE_DATE as required -- a couple of times per release cycle, maybe a few more if the schedule slips repeatedly -- would constitute a significant additional maintenance burden.