Date: Wed, 24 Jan 2001 22:44:30 +0200 From: Mark Murray <mark@grondar.za> To: Jeroen Ruigrok van der Werven <jruigrok@via-net-works.nl> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/contrib/tcpdump print-smb.c Message-ID: <200101242044.f0OKiGI72820@gratis.grondar.za> In-Reply-To: <20010124202607.A1455@lucifer.bart.nl> ; from Jeroen Ruigrok van der Werven <jruigrok@via-net-works.nl> "Wed, 24 Jan 2001 20:26:07 %2B0100." References: <20010124202607.A1455@lucifer.bart.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
> The point everybody is failing to see here is not repo bloat.
I hope that all folks are seeing a balanced picture.
> The point is maintainability and having just spend two days just trying
> to get awk MFC'd correctly I think that both David and my points in time
> [we've had this discussion before, and so many other discussion as well
> that I am growing quite weary of them by now] have been on the case of
> maintainability.
OK, so "repo bloat" and "merge conflicts" are problems.
> Not to belittle anyone, but David and me are currently two of people,
> out of a score of more, who actively deal a lot with contrib'd sources
> and their subsequent MFC's, and we can readily attest that taking files
> of the vendor branch is not making our task that much easier.
> Sure, there exist tools which make this easier, but cause other problems
> for our project.
... But they are not the only problems. CVS is there to allow us to
focus on the essence of the problem. If that comes down to a "fix
conflicts", then so be it.
There seems to be a "conflicts are the ultimate evil!!" approach here,
and that is just plain crazy! (Yeah, Yeah. I'm being a bit extreme,
but that is just to make my point.)
> And another aside, if Archie would've consulted with the other
> developers or directly with David or me we could've advised him to
> merely import this as a patch on along on the vendor branch, causing
> less problems for us all.
That is one way to do it. But "Vendor branch is a tool, not a
panacea, nor a mantra". Can we get a sense of balance here, and
try to avoid extreme/absolute positions? The porting system works
very well with just-plain-diff(1). Methinks that the base system
is doing very well with the tools that ${WE} have, and the latitude
that CVS accords us is used as intended (not further constrained
- obviously excepting the "usual" rules breakage required by the
repo-distribution tools and the TAG-maintenance requirements).
M
--
Mark Murray
Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101242044.f0OKiGI72820>