Date: Fri, 20 Apr 2012 11:18:16 -0700 (PDT) From: Pedro Giffuni <pfg@freebsd.org> To: jasone@freebsd.org, Doug Barton <dougb@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: contrib/jemalloc Message-ID: <1334945896.68082.YahooMailClassic@web113507.mail.gq1.yahoo.com> In-Reply-To: <4F919E11.6040807@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi;=0A=0A--- Ven 20/4/12, Doug Barton ha scritto:=0A...=0A> > =0A> > The wo= rkflow I'm using is documented in the patch=0A> (contrib/jemalloc/FREEBSD-u= pgrade).=A0 Can you tell me=0A> how to achieve a similarly streamlined impo= rt flow with a=0A> vendor branch in the mix?=A0 Also, what history would a= =0A> vendor branch preserve that this workflow does not?=A0=0A> The only up= side to vendor branch merges I can think of is=0A> that if any jemalloc sou= rces were manually modified between=0A> imports, merging would fail rather = than silently overwriting=0A> the changes.=A0 However, this presumes that c= hanges=0A> aren't making it upstream.=0A> =0A> I attempted to engage you ab= out this on the svn list and=0A> apparently you ignored my message. David i= s right, what=0A> you're doing is not even close to our normal work flow.= =0A> It would actually be easier for you (and those=0A> who may be maintain= ing this after you're gone) for you to do=0A> things the way that we normal= ly do them.=0A>=0A=0AFWIW,=0A=0AWhile the vendor branch is usually the clea= nest way to merge=0Aupdates, it is not always the best. I personally gave u= p on=0Aupdating two packages from the vendor tree because it's just=0Atoo m= uch trouble. In this case it's likely that the committed=0Ajemalloc is very= FreeBSD specific and doesn't really match the=0Amore generic version.=0A= =0AINHO, being that the committer is also the author it is likely=0Ahis pre= rogative how to update it.=0A=0Acheers,=0A=0APedro. =0A
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1334945896.68082.YahooMailClassic>