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
>=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=
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"