From owner-freebsd-ports@FreeBSD.ORG Tue Nov 11 10:11:25 2003 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DCDF16A4CE for ; Tue, 11 Nov 2003 10:11:25 -0800 (PST) Received: from smtpout.mac.com (A17-250-248-85.apple.com [17.250.248.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A05343FE3 for ; Tue, 11 Nov 2003 10:11:22 -0800 (PST) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id hABIBMIZ027581 for ; Tue, 11 Nov 2003 10:11:22 -0800 (PST) Received: from [10.1.1.193] (dpvc-68-161-244-25.ny325.east.verizon.net [68.161.244.25]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id hABIBLZq017381 for ; Tue, 11 Nov 2003 10:11:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <20031111021929.GA17050@xor.obsecurity.org> References: <1068458390.38101.19.camel@dirk.no.domain> <20031110152000.622db381.lehmann@ans-netz.de> <1068471598.38101.77.camel@dirk.no.domain> <20031110163623.GC93583@procyon.firepipe.net> <1068495958.690.72.camel@leguin> <53EC784E-13C5-11D8-AD24-003065ABFD92@mac.com> <3FB00E53.8060603@fillmore-labs.com> <20031111021929.GA17050@xor.obsecurity.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <73E9F604-1472-11D8-BD31-003065ABFD92@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 11 Nov 2003 13:11:21 -0500 To: freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.606) Subject: Re: Ability for maintainers to update own ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2003 18:11:25 -0000 On Nov 10, 2003, at 9:19 PM, Kris Kennaway wrote: > On Mon, Nov 10, 2003 at 11:16:51PM +0100, Oliver Eikemeier wrote: >> The first can be satisfied with something like pkgsrc-wip, and I >> always >> wondered why we don't have a ports-FRESH and ports-TESTED, like we >> have >> -CURRENT and -STABLE. > > Because even with a single, unbranched ports collection, committers > can't keep it in working order without significant ongoing effort. On > average, several ports become broken on one of the supported > architectures and versions, *each day*. [ ... ] Thanks for your insight into the scope of the problem, Kris: as one of the 's, I suspect that you've dealt with more than a few variations on how the ports system can break. More to the point, I regretfully agree that branching ports probably would hurt more than it would help. There is the issue of "MFC'ing" a port from HEAD to the -STABLE branch (or -TESTED, or whatever name)-- dealing with CVS branches is hard (or at least more error-prone) for even for developers who are relatively experienced. It would add a significant amount overhead to the CVS repo, and multiply the number of environments to be tested, the number of failures, and so forth, just as you've said. > If you start adding more branches to the ports collection, you're > going to multiply the possible failure modes, and the net result will > be that the number of errors accumulating in the ports collection will > more than multiply. Branching the ports collection is not a helpful solution to the problem of speeding up the rate at which ports are committed. Branching ports might help out people who try to update their ports while running older versions of FreeBSD (yes, I understand that supporting older versions is at a low priority, but this would address some user expectations/complaints), and it might smooth "cataclysmic events" involving changes to the ports infrastructure, changes to -CURRENT which break lots of ports, etc. However, I'm not sure we need to branch the ports CVS repository to address these issues: what happens if we use CVS tags to indicate which OS versions and/or hardware architectures a port works on? One could then have successful builds on bento perform the tagging in an automated fashion. This might provide many of the benefits, without incurring a lot of additional work on the part of committers. -- -Chuck