From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 20:20:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1AC5106564A; Thu, 12 Apr 2012 20:20:03 +0000 (UTC) (envelope-from jasone@canonware.com) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id 795F68FC0A; Thu, 12 Apr 2012 20:20:03 +0000 (UTC) Received: from [172.25.16.174] (unknown [173.252.71.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id E6ACD2843B; Thu, 12 Apr 2012 13:19:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jason Evans In-Reply-To: <20120412184114.GB71001@dragon.NUXI.org> Date: Thu, 12 Apr 2012 13:19:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <431CB493-836B-4DF4-AC42-A7C6ABF7DE3E@canonware.com> <20120412184114.GB71001@dragon.NUXI.org> To: obrien@freebsd.org X-Mailer: Apple Mail (2.1257) Cc: freebsd-current@freebsd.org Subject: Re: contrib/jemalloc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jasone@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 20:20:03 -0000 On Apr 12, 2012, at 11:41 AM, David O'Brien wrote: > On Wed, Apr 04, 2012 at 09:56:45PM -0700, Jason Evans wrote: >> I have the current version of jemalloc integrated into libc as = contrib/jemalloc: >> = http://people.freebsd.org/~jasone/patches/jemalloc_20120404b.patch >=20 > Looking at the latest patch > http://people.freebsd.org/~jasone/patches/jemalloc_20120405a.patch >=20 > I cannot tell for sure if you did an 'svn move' of the files from > lib/libc/stdlib/ to contrib/jemalloc/. It looks to me like they have > not. If not, can you regen the diff after using 'svn move' so we > maintain log history? Done now for malloc.3 --> reallocf.3 in my tree. = http://people.freebsd.org/~jasone/patches/jemalloc_20120412a.patch For the rest of the code, its structure/origin is different enough that = 'svn move' doesn't really apply. >> * Is it acceptable to check this in directly to trunk without using a >> vendor branch? For the import workflow I have planned, a vendor = branch >> would just be extra work with no benefit that I can see. >=20 > I do not think it is acceptable. Our workflow is to do vendor = imports. > They are invaluable in tracking down history and changes years after = the > fact. They are also very valuable to commercial third-parties that > consume FreeBSD into their products (I speak for Juniper Networks in > this). >=20 > Why do you feel they are [measurably] extra work with no benefit? The workflow I'm using is documented in the patch = (contrib/jemalloc/FREEBSD-upgrade). Can you tell me how to achieve a = similarly streamlined import flow with a vendor branch in the mix? = Also, what history would a vendor branch preserve that this workflow = does not? The only upside to vendor branch merges I can think of is = that if any jemalloc sources were manually modified between imports, = merging would fail rather than silently overwriting the changes. = However, this presumes that changes aren't making it upstream. Jason=