Re: contrib/jemalloc

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_at_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_at_FreeBSD.org)