Re: contrib/jemalloc

From: Doug Barton <dougb_at_FreeBSD.org>
Date: Sat, 21 Apr 2012 00:23:00 -0700
On 04/20/2012 06:06 PM, Pedro Giffuni wrote:
> On 04/20/12 19:32, David O'Brien wrote:
>> On Fri, Apr 20, 2012 at 02:13:32PM -0700, Pedro Giffuni wrote:
>>> Easier said than done. Feel free to give libedit a try.
>> That has nothing to do with our process and everything to do with us
>> blindly hacking away pissing all over to be our own thing -- BUT still
>> wanting to take work from the original author.
>>
>> I fail to see how not updating thru $FBSDrepo/vendor/NetBSD/libedit
>> is easier than updating thru it.
>>
>> Either way you have to figure out what to do with our great divergance.
>> At least when using the vendor branch you can use a good 3-way diff merge
>> tool (e.g. svn).
>>
> 
> Usually the vendor upgrade approach works just fine if we do
> the periodic work of keeping up to date and we are careful to
> submit our changes upstream.

That's an expected part of the role of maintainer, so, yeah. :)

> The issue is that you really have to be in sync with one upstream
> version so that the changes you merge from the vendor branch
> are consistent.

To a large extent, yes.

> In libedit we have incomplete merges from upstream (that was
> CVS fault), we have some changes that are obsolete wrt to how
> upstream solved the same issues and we have a couple of
> files that have diverged completely from upstream.

I agree that sounds like an ugly mess ... who is working on cleaning it
up? Is this something that we need to create a team to address? It
certainly sounds like something too large for one person to handle on
their own.

> Either way it all can all be solved but it's just a lot of work and I
> can see how the direct approach helps understand better what
> is happening and can ultimately save time.

I'm glad we have an area of agreement. It sounds to me like the lesson
from libedit is to do it right from the very beginning, so that things
like libedit don't happen again.

Doug
Received on Sat Apr 21 2012 - 05:23:01 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:26 UTC