Date: Wed, 22 Feb 1995 18:36:56 -0700 From: Nate Williams <nate@trout.sri.MT.net> To: "Jordan K. Hubbard" <jkh@freefall.cdrom.com> Cc: current@freefall.cdrom.com Subject: Re: TRUE and FALSE Message-ID: <199502230136.SAA16736@trout.sri.MT.net> In-Reply-To: "Jordan K. Hubbard" <jkh@freefall.cdrom.com> "Re: TRUE and FALSE" (Feb 22, 4:37pm)
next in thread | previous in thread | raw e-mail | index | archive | help
> Look, right now we have an intolerable situation where we have this > mutant world target from hell that requires updating each and every > time some weird bogon in the tree requires that it be updated in a > specific sequence before anything else will work. Yes, and that will not change with the solution proposed. There will *always* be tool dependencies in the tree. That's why GCC still has a bootstrap target. The only thing a self-hosting tree will buy you is one less iteration to build things. Dependency will always exist, since you can't build libraries until you upgrade the library build-tools, and you can't build utilities w/out the libraries, so you may need to do a couple iterations to get things up to snuff, hence the 'world' target. > It's already > tripled in size since we first created it and it's not at all > inconceivable that (if things keep going this way) the world target > will be 3 pages long by the time 2.2 comes out! That or we'll finally > run into a case we can't solve with one pass and we'll end up with > multiple sub-makes from the darkest reaches of Hades! Welcome to tool dependencies and changing source trees. That's life. > That and the simple fact that depending on includes and libraries > from outside of /usr/src is incredibly *error prone*. If you and > Garrett feel so strongly about this, then I have a suggestion: > > YOU BE THE RELEASE ENGINEERS FOR 2.1! Get off of it. This always comes up, and all it does is ruffle feathers. You don't have to be release engineer to understand some of the issues required to do it. Heck, all of us do (our at least should do) our own little 'release' engineering work before we integrate patches into the tree. It's not as large as the main work, but it does mean we have a clue on doing releases. I *couldn't* be the release engineer even if you paid me $100K to do it. > incredibly irksome to be one of the ones bitten by this and then be > corrected by the two people here who have NEVER done a release and > have always run rapidly in the other direction every time the hat was > passed around for a volunteer to actually do this grueling task! Trust me, I've done release engineering, and you have also. Remember the patchkit. Do't give me this 'NEVER done a release' crap. > you know that the 950210-SNAP release has a bogus ps ... > Now you can argue that I should have gone through the arduous process > of doing a make world first, or perhaps a make install then a chroot > then another make all and ... but I didn't have a full 24 hours to tie > up my machine with this at the time, so I took what looked like a > reasonably short cut and it bit my ass. This should NOT HAVE HAPPENED > and if we had a properly designed source tree it WOULD NOT HAVE. Sheesh. If you don't have 24 hours to make a completely public release of the software, then maybe it's time for you to quit making them. Before I even commit patches to the tree I run them for over 48 hours in make world regression tests. To not take the extra 24 hours to make sure it's up to date seems rather silly. Starting from a running system, you are guaranteed to get everything working with 2 make worlds, and a 3rd certainly shouldn't hurt. > Now Poul-Henning is proposing a final solution to this mess and you There is no solution proposed. What was proposed was filling up /usr/include from files in /sys, instead of using symlinks as it is now. Nothing else was proposed. Don't get all huffy and mighty. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502230136.SAA16736>