cvs commit: src/contrib/bind9 - Imported sources
oberman at es.net
Sat Sep 25 18:36:41 PDT 2004
> Date: Mon, 20 Sep 2004 14:54:03 -0600 (MDT)
> From: "M. Warner Losh" <imp at bsdimp.com>
> Sender: owner-cvs-all at freebsd.org
> In message: <20040920182901.GA40865 at madman.celabo.org>
> "Jacques A. Vidrine" <nectar at freebsd.org> writes:
> : On Mon, Sep 20, 2004 at 11:19:03AM -0700, David O'Brien wrote:
> : > This should have been discussed in public if we were to break with 8
> : > years of standard operating practice.
> : You need to come up with a better argument than "we did it that way for
> : 8 years".
> Don't you need a better argument than 'We thought it was different?'
> that knife cuts both ways. David is correct in that we've always done
> new version on top of the old versions to preseve history. What makes
> bind9 so different than gcc, binutils, texinfo, tcpdump and all the
> others? The burdon of proof is on the person breaking with SOP, not
> the person complaining that SOP is being violated.
> : > How long is src/contrib/bind going to stick around? Why does it need to
> : > exist at the same time as src/contrib/bind9?
> : BIND 9 is a completely different code base than BIND 8. Importing
> : BIND 9 over BIND 8 would be very confusing from the point of view
> : of CVS history. BIND 8 will be with the 4.x branch for a long time
> : still (e.g. I'm projecting May 2006 before we stop issuing security
> : advisories for 4.x). It is very welcome that there will not be
> : entangled/interleaved history between FreeBSD 4.x/BIND 8 commits and
> : FreeBSD 5.x/BIND 9 commits.
> What are you talking about? The history is separate for each branch,
> so that's a fairly lame argument.
> : Out of the 1,189 BIND 8 files and 2,100 BIND 9 files, there are only 8
> : files that are in the same place. It would cause a confusing mess to
> : import this over src/contrib/bind and it would offer no benefit that I
> : can see.
> That, however, is a decent reason. Thanks. You should have just said
> that in the first place, rather than be argumentative with David. It
> would have saved some sniping back and forth. Let's learn from this
> in the future and remember it if/when we break from tradition again.
This one is really a case of awk vs. one-true-awk. It is a totally new
code base from a different author.
BIND 4 was originally written by the CSRG folks, as I'm sure many of you
know. It was an awful mass of spaghetti and became something no one
wanted to touch after the CSRG contract for BSD ended.
When it had become obvious that BIND had to be updated, Paul Vixie was
crazy enough to take the job. He worked on BIND and started on
reorganizing the code and bringing it up to date. But he soon realized
that he needed some backing and help. Enter ISC, founded by Paul to get
support to pay people to work on a real BIND re-write. The result became
BIND 8, although the same people worked on later releases of BIND 4.
Then came the Internet bubble and the need to update BIND again. Paul
decided that the best way to get people to work on BIND was to start a
company to write it completely from scratch with the financial backing
of the ISC. This was to be a clean re-write with no code from the old
version. The people writing the code were not to even reference the code
for prior versions. This was because Paul felt that some of the
copyrights were at least cloudy and a complete re-write would end any
issues. Note that BIND 9 has no BSD copyright notice.
So, even by David's standards, BIND 9 is different code from different
writers with a different copyright and ownership. And, as pointed out,
it has virtually nothing in common with bind.
If there is any doubt, we can always ask Paul V. for confirmation that
BIND 9 is a totally new code base. /usr/contrib/bind9 is clearly the
right place for this, IMHO.
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net Phone: +1 510 486-8634
More information about the cvs-all