From owner-cvs-all Wed Jan 24 10:28: 3 2001 Delivered-To: cvs-all@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id D7FDB37B400; Wed, 24 Jan 2001 10:27:37 -0800 (PST) Received: from [128.113.24.161] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id NAA479896; Wed, 24 Jan 2001 13:27:31 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Wed, 24 Jan 2001 13:26:52 -0500 To: John Baldwin , Archie Cobbs From: Garance A Drosihn Subject: Re: cvs commit: src/contrib/tcpdump print-smb.c Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Kris Kennaway Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In this discussion, it was noted: >See the committers guide, it has a FAQ for this: > >http://www.freebsd.org/tutorials/committers-guide/article.html > > > >10.1. Why are trivial or cosmetic changes to files on a vendor > branch a bad idea? > >The RCS file format is quite braindead [...skipping...] > >This is why we have such ``hands off'' policies for src/contrib >and other things that track the vendor releases. This is why >``typo fixes'' in man pages and spelling ``corrections'' are so >strongly discouraged for vendor code. > > I think this FAQ entry describes the situation quite fine. We should NOT make "typo fixes" or "spelling corrections". I agree completely. Now, back to this thread. Archie fixed a BUG. A BUG. That is not a typo on a man page. It is not a spelling correction. IT IS A BUG. If I am using tcpdump to look at SMB packets, I would much prefer to SEE THE CORRECT OUTPUT than to worry about a little cvs bloat. This is particularly true if I'm grepping thru a few thousand packets for a specific character string, and I get false-matches because tcpdump is tacking on random crap that it shouldn't be showing in the first place. If we're going to whine this much about fixing bugs, we're in pretty sad shape. Yes, it would be nice if the "vendor" (in this case) picked up the fix, and we did not have the repository bloat. On the other hand, IF the vendor has a history of being unresponsive, are we supposed to ignore BUGS? It might even be that the vendor will be more responsive if the person fixing the bug can say "Hey, we've had this fix in freebsd for 2 months, and it hasn't caused any problems". What I don't know is how the repository is effected if the vendor does (later on) include this patch. Do we automatically switch to following the "official vendor version" at that point, or do we keep adding to the repository bloat because we branched off at the earlier point? -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message