Date: Thu, 12 Apr 2012 13:19:56 -0700 From: Jason Evans <jasone@canonware.com> To: obrien@freebsd.org Cc: freebsd-current@freebsd.org Subject: Re: contrib/jemalloc Message-ID: <A29E26F5-2324-4DE2-BD61-7EBA3245AF43@canonware.com> In-Reply-To: <20120412184114.GB71001@dragon.NUXI.org> References: <431CB493-836B-4DF4-AC42-A7C6ABF7DE3E@canonware.com> <20120412184114.GB71001@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A29E26F5-2324-4DE2-BD61-7EBA3245AF43>