Date: Fri, 13 Apr 2012 15:43:03 -0700 From: "David O'Brien" <obrien@freebsd.org> To: jasone@freebsd.org Cc: freebsd-current@freebsd.org Subject: Re: contrib/jemalloc Message-ID: <20120413224303.GA89952@dragon.NUXI.org> In-Reply-To: <A29E26F5-2324-4DE2-BD61-7EBA3245AF43@canonware.com> References: <431CB493-836B-4DF4-AC42-A7C6ABF7DE3E@canonware.com> <20120412184114.GB71001@dragon.NUXI.org> <A29E26F5-2324-4DE2-BD61-7EBA3245AF43@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 12, 2012 at 01:19:56PM -0700, Jason Evans wrote: > 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 ... > >> * 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? Hi Jason, It looks like you could run './FREEBSD-upgrade extract' from a check out of ssh://svn.freebsd.org/base/vendor/jemalloc. I'm unclear what the './FREEBSD-upgrade rediff' step is for. I'm having trouble following what "then regenerate diffs to update line offsets" is for. How do you handle the difference between FreeBSD having include/malloc_np.h and your GIT repo having jemalloc/include/jemalloc/jemalloc.h[.in]? Does './FREEBSD-upgrade extract' or './FREEBSD-upgrade rediff' patch 'include/malloc_np.h' and 'include/stdlib.h'? Especially with the '#define JEMALLOC_P(s) s' wrapping. Is that part of the './FREEBSD-upgrade rediff' step? Can you nudge me in the right direction to understanding this workflow? Typically the tracking of diffs between what's in your vendor GIT repo and FreeBSD comes from the FreeBSD SCM system. A combination of 'svn diff ^/vendor/jemalloc/dist ^/head/contrib/jemalloc' and 'cd contrib/jemalloc && svn merge ^/vendor/jemalloc/dist'. > Also, what history would a vendor branch preserve that this workflow > does not? contrib/jemalloc/FREEBSD-upgrade doesn't describe the "commit into FreeBSD subversion repo" step, that I can see. So I am not sure what gets committed vs. what's in git://canonware.com/jemalloc.git. > 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. I feel that is an important check-and-balance. Not following our established procedure also means that the average developer(committer) and commercial consumer will have their expectations fails. One expects to be able to find the stock vendor sources in ssh://svn.freebsd.org/base/vendor/ and to be able to find FreeBSD local changes to the sources thru 'svn diff' against ssh://obrien@svn.freebsd.org/base. > However, this presumes that changes aren't making it upstream. That is not an unreasonable presumption. Unless contrib/jemalloc/ is locked so that you are aware of every commit FreeBSD and git://canonware.com/jemalloc.git can diverge at times. -- -- David (obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120413224303.GA89952>