From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 22:32:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E3AD106564A; Fri, 2 Apr 2010 22:32:12 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id BD4358FC08; Fri, 2 Apr 2010 22:32:11 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-253-149.belrs3.nsw.optusnet.com.au [122.106.253.149]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o32MW8oc000508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Apr 2010 09:32:09 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o32MW27M039461; Sat, 3 Apr 2010 09:32:02 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o32MW2fw039460; Sat, 3 Apr 2010 09:32:02 +1100 (EST) (envelope-from peter) Date: Sat, 3 Apr 2010 09:32:02 +1100 From: Peter Jeremy To: Jeremy Chadwick Message-ID: <20100402223202.GD86236@server.vk2pj.dyndns.org> References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> <20100402.122836.41723967.sthaug@nethelp.no> <4BB5CAA7.5030108@stillbilde.net> <20100402121526.GA64746@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pZs/OQEoSSbxGlYw" Content-Disposition: inline In-Reply-To: <20100402121526.GA64746@icarus.home.lan> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) X-CMAE-Score: 0 Cc: freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 22:32:12 -0000 --pZs/OQEoSSbxGlYw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Firstly, congratualtions to doubg@. On 2010-Apr-02 05:15:26 -0700, Jeremy Chadwick w= rote: >1) In most scenarios (historically speaking), what gets updated quicker: >base or ports? Answer: ports. In some ways this is a problem. On the downside, it means that a -RELEASE will never have bleeding edge features. On the upside, it means that a -RELEASE will never have bleeding edge bugs. >2) What has proper infrastructure for dependencies and tracking of >installed files as part of a software package? Answer: ports. I agree that this is a deficiency in the base system. I have often wished that there was some way of tracking exactly what part of installworld had installed what file - but I accept that this is a "difficult" problem. It might be useful if there was a target as part of install{world,kernel} that built a mtree database of what was installed. >3) How often do you see people posting problems with key pieces of >FreeBSD infrastructure (device support/reliability or storage-related >subsystems), followed by a response from a developer stating "this has >been fixed in -STABLE" or "can you try the code from HEAD?" Answer: >often. That's true of any non-trivial piece of software that has distinct "developer" and "end-user" branches. Moving to ports won't really resolve the problem - the answer will still be "you need to update to a newer version of that code". Whilst I'd occasionally like to see less "bloat" (ie anything that I don't use) in base, there is one significant benefit that I don't recall seeing discussed in this thread - integration testing. The base system it built and tested as a whole. This isn't practical for the ports system. Without the integration testing, you wind up in the situation where port A and port B work in isolation but don't work together - the port A maintainer says that the problem is port B and the port B maintainer says that port A is relying on an optional part of port B that they don't have the time/interest/expertise to maintain. --=20 Peter Jeremy --pZs/OQEoSSbxGlYw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAku2cGIACgkQ/opHv/APuIeMgQCggvdT7V76Zm2JuS/1z31DB6HK WG0An35J/TIm1aiTSJCzOx3GpPC6yhxM =gusw -----END PGP SIGNATURE----- --pZs/OQEoSSbxGlYw--