Date: Wed, 19 Jun 1996 09:11:24 -0600 From: Nate Williams <nate@sri.MT.net> To: Poul-Henning Kamp <phk@freebsd.org> Cc: Nate Williams <nate@sri.MT.net>, current@freebsd.org Subject: Re: tcl -- what's going on here. Message-ID: <199606191511.JAA05842@rocky.sri.MT.net> In-Reply-To: <1867.835165278@critter.tfs.com> References: <199606190523.XAA04861@rocky.sri.MT.net> <1867.835165278@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 1. People will have to make their changes as patches this way. > > > >CVS does that for us. Having 'patches' doesn't buy us anything when > >it's a critical portion of the tree. > > Sorry, but available history shows that this, true as it may be in > theory, doesn't work in practice. On the otherhand we get patches > from the ports collection integrated at the authors all the time. If you use it it works. Just because you aren't using it doesn't mean it doesn't work. It worked for CVS, which is a pretty large package. > >> 2. It makes communication with the author(s) easier that we know what > >> our changes actually are. > > > >When a person sends diffs, either the author accepts them or he doesn't. > >TCL changes *radically* from stable version to version, so importing it > >via a vendor branch makes it *much* easier to see vs. having to go find > >out by where in the patch fits. > > Considering what you claimed to know about Tcl, I think you lack data > for saying that TCL changes "*radically*" here. It hasn't for a long > time. 7.3 -> 7.4 == Radical change 7.4 -> 7.5 == radical change because of all the changes necessary for the other OS's. This was from the announcement from Dr. Ousterhout. You don't have to be an expert in a language to understand the concept of 'radical changes'. > >> 3. It makes it easier for people to experiment with a never version > >> on their own. > > > >Ports already allows for this. > no. > > Try gcc for a prime example of how it doesn't work. Huh? There are lots of folks using the PGCC port. > >> 4. It takes up LESS space. > > > >BS. The *first* version takes up less space, but for every version > >afterwards it takes up *incredibly* more space. Every new import > >effectively doubles the space, since there is probably < 10% overlap in > >a uuencoded gzip file. > > du(1) our gcc versions to see if that holds water :-) I just did. It looks pretty good considering how many changes have been we've made. root:/home/CVS/src/gnu/usr.bin/cc # du -s 12530 . root:/usr/src/gnu/usr.bin/cc # du -s 11534 . We're doing a darn good job of keeping things small. The CVS repository is less than 10% larger with *ALL* of the revisions than the actual source code. (Bad example, it actually encourages using CVS) > >> The discussion ? well, I have tried to start it several times, and > >> nobody seemed to care, so they obviously cannot feel too much about it > >> ? > > > >BS. I've argued against through email and in personal conversation. > >But Jordan agreed so it didn't matter. > Nate, curb your paranoia. There havn't been any discussion, because > it wasn't possible to start one. Curb your paranoia. There *was* an attempt to start a discussion but no-one wanted things changed. I have the email to prove it, so don't tell me no-one cared. > There still isn't, only a lot of > shouting from various "usual suspects" who are not willing to put up > with the maintenance of any of this stuff themselves. BS. Peter's doing the gcc port. I've done some of the 'trivial' ports, and done some of the gcc stuff. I've also done CVS (non-trivial) and plan on upgrading flex sometime soon. I haven't done a 'from-scratch' update any of groff/uucp/gcc, but those are the only *huge* ones, but because I haven't doesn't mean I'm incapable of understanding how difficult it is. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606191511.JAA05842>