Date: Wed, 19 Jun 1996 09:27:31 -0600 From: Nate Williams <nate@sri.MT.net> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Nate Williams <nate@sri.MT.net>, Poul-Henning Kamp <phk@freebsd.org>, current@freebsd.org Subject: Re: tcl -- what's going on here. Message-ID: <199606191527.JAA05879@rocky.sri.MT.net> In-Reply-To: <22601.835171642@time.cdrom.com> References: <199606190523.XAA04861@rocky.sri.MT.net> <22601.835171642@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Bullying people around isn't the best way to get things done. It does > > do a good job of getting people angry though. > > Well, I don't think Poul was up for bullying so much as he himself is > somewhat frustrated by the lack of response to previous attempts to do > something *like* this (note emphasis) and hasn't had much in the way > of response from people. I remember some *negative* responses myself, and can post them if need be. > In all fairness to Poul, we *have* been discussing a scheme like this > for over a year now and I've never seen it come anywhere comfortably > close to closure - the religious issues never do, somehow. See Bruce Evan's post. There is *no* need to change the current scheme. For *major* subsystems such as gcc we *shouldn't* change it often, and having it tightly coupled is a good thing. > I think we should also consider what we've gained here, namely the > "middle ground" between ports and src which we always knew was in our > future someday but have steadily tried to avoid. How is this any different from a port that sits in the tree, except for the bogus uuencoded tar-file in the Repository? > We knew it was in > our future because the prospect of re-bmaking every port we ever > wanted to ugrade, now and in the future, has traditionally _sucked_ > and we've hated it from day one. I agree with Bruce in that 'they aren't broke, so I don't have a burning desire to go fix them'. I'd have done flex a *long* time ago but the need to upgrade it is so slight to make it one of those 'down on the bottom of my list' things. It works great the way it is, so why bother upgrading. And, it doesn't take a *huge* amount of time to upgrade. Heck, PHK's 2.6 upgrade took less than 8 hours after the 2.6 release before he imported it into the tree, so it can't be *that* bad. > I know you've always liked the old scheme, but I don't think I ever > saw you raise your hand to become "bmake czar for eternity" either :-) But I'm willing to 'bmake' code (and have done so) in the same manner as I'm willing to generate code and integrate other bug fixes. No-one is solely responsible for doing any one task in the tree. It's something we all share. > > BS. I've argued against through email and in personal conversation. > > But Jordan agreed so it didn't matter. > > Oh c'mon Nate, this has nothing to do with some grand decision from > yours truly - this is simply the next logical step for things which > occupy the 3rd logical category of software - things which we need in > our base distributions but don't want to have to necessarily maintain > fully as FreeBSD components. Trying to deny the existance of a 3rd > category, smashing things into either /usr/src or /usr/ports, has come > at great cost on both sides. Either you're in bmake hell or you can't > rely on the feature at all because the ports collection isn't a > non-optional part of the system. This fact doesn't take an Einstein > to see, it's been obvious for a long time, and the fact that *neither* > of us has ever come up with a credible alternative is what led me to > stand out of the way when Poul decided to do what he did. I still disagree. Code maintenance is *critical* for anything that's a required part of the tree. It takes time to make it work, and spending the time to make it work in the tree is simply the cost of doing business. Should we forgot doing other platforms since it'll be too much work. The fact of the matter is that it 'doesn't take an Einstein to see that there are still lots of machine dependant code inside of our machine independant tree which will mean we will have a great loss of time changing our code to be better.' The best solution is to simply 'import' the NetBSD code into a different part of the tree (rather than merging it into our scheme) and re-badge it 'in the tree' and 'viola' we've gotten a bunch of new ports. This is akin to what's been done. > Unless > you've come up with some way of eliminating the bmake-munging process > for ports like gcc and groff Unless you can say that NO-ONE is willing to do the bmake-munging process for them, then this is a moot point. Apparently Peter already did, and I don't see a burning need for doing groff. However, having said that I *will* do groff if you feel that upgrading groff is more important the the laptop work. This also means that the current integration work I'm trying to do with Hosokawa will fall even further behind and make things more difficult later. *IF* you think that these things are critical, then say something about it and let the rest of us agree/disagree. Only then can you say that 'we need a better solution'. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606191527.JAA05879>