On 04/21/12 02:23, Doug Barton wrote:
...
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 lik
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 hac
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 st
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 origina
On 04/20/2012 02:13 PM, Pedro Giffuni wrote:
>
>
> --- Ven 20/4/12, Doug Barton ha scritto:
> ...
>>
>> With due respect, if doing it the right way is too
>> difficult, the answer
>> is to ask for help rather than giving up. There are plenty
>> of us who are
>> experienced with doing this, and w
--- Ven 20/4/12, Doug Barton ha scritto:
...
>
> With due respect, if doing it the right way is too
> difficult, the answer
> is to ask for help rather than giving up. There are plenty
> of us who are
> experienced with doing this, and would be glad to assist.
>
> In the CVS era I agree that v
On 04/20/2012 11:18 AM, Pedro Giffuni wrote:
> FWIW,
>
> While the vendor branch is usually the cleanest way to merge
> updates, it is not always the best. I personally gave up on
> updating two packages from the vendor tree because it's just
> too much trouble.
With due respect, if doing it the
Hi;
--- Ven 20/4/12, Doug Barton ha scritto:
...
> >
> > 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 pre
On 4/12/2012 1:19 PM, Jason Evans wrote:
> On Apr 12, 2012, at 11:41 AM, David O'Brien wrote:
>>>
>>> * 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
On Apr 13, 2012, at 3:43 PM, David O'Brien wrote:
> 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:
> It looks like you could run './FREEBSD-upgrade extract' from a check out
> of ssh://svn.freebsd.org/base/vendor/jemalloc.
>
> I'm
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.freebs
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
>
> Looking at the la
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/jemall
On Apr 5, 2012, at 6:33 AM, John Baldwin wrote:
> On Thursday, April 05, 2012 12:56:45 am Jason Evans wrote:
>>
>> * Will the utrace feature be missed? I removed it some time ago, mainly
>> because traces are impossibly large for most real-world use cases.
>
> I will only speak to this one. I
On Apr 5, 2012, at 10:52 AM, Konstantin Belousov 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
>
>> * Are t
On Thu, Apr 05, 2012 at 11:55:48AM -0700, Jason Evans wrote:
> On Apr 5, 2012, at 10:52 AM, Konstantin Belousov 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://pe
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
> * Are the symbol versioning specifications right, and are the
> compati
On Thursday, April 05, 2012 12:56:45 am 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
>
> This is the first update to FreeBSD's jemalloc in over two years, and t
18 matches
Mail list logo