Re: contrib/jemalloc

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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"