Date: Thu, 12 Apr 2012 11:41:14 -0700 From: "David O'Brien" <obrien@freebsd.org> To: jasone@freebsd.org Cc: freebsd-current@freebsd.org Subject: Re: contrib/jemalloc Message-ID: <20120412184114.GB71001@dragon.NUXI.org> In-Reply-To: <431CB493-836B-4DF4-AC42-A7C6ABF7DE3E@canonware.com> References: <431CB493-836B-4DF4-AC42-A7C6ABF7DE3E@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > * 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? -- -- David (obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120412184114.GB71001>