Re: contrib/jemalloc

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
> 
> Looking at the latest patch
> http://people.freebsd.org/~jasone/patches/jemalloc_20120405a.patch
> 
> 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.
> 
> 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).
> 
> 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