Date: Wed, 11 Mar 1998 12:47:40 -0500 From: Gary Schrock <root@eyelab.psy.msu.edu> To: Mike Smith <mike@smith.net.au> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: *HEADS UP* Correction to previous postings. Message-ID: <199803111753.MAA10778@eyelab.psy.msu.edu> In-Reply-To: <199803111125.DAA22879@dingo.cdrom.com> References: <Your message of "Mon, 09 Mar 1998 14:17:12 EST." <199803091924.OAA01358@eyelab.psy.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
At 03:25 AM 3/11/98 -0800, you wrote: >The change has been tested in its original form on one system for >nearly three years now. I tested it in every fashion that I was able >to, and attempted to document the characteristics of the change to the >best of my ability. And from the discussions going on on the lists about other cases this code doesn't handle, that wasn't sufficient. >It was committed to -current. The change significantly simplifies >portions of the installation procedure, and will result in a smoother >upgrade path to 3.0. >From looking at the cvs logs, it looks like it was committed to current less than 24 hours before it was committed to stable. And meanwhile stable was starting to gear up to try to do a release. IMHO that's just asking for trouble. >I appreciate your concern. However, I suspect that you should consider >who is really responsible for verifying that your system(s) will operate >in a fashion that is consistent with your preferences. > >Perhaps it might be wise to test your remote configurations locally >before deploying them remotely? It wouldn't be the first time if you >ran into a change which had been committed in all innocence on the >expectation that it would be harmless but later turned out to be a >killer. I always do test things locally to make sure they're working on machine I can walk over and reboot. However, I don't have access to a system that matches the exact configuration that the remote machine is, so there's always a risk. Anytime I have to reboot the remote machine I sort of cringe and hope it comes back up. Beyond that, there's just a limit to what I can do. >The compatability clause will probably exist in more or less the same >form through at least the first release of 3.0. But in the case you're >discussing, if you can get a kernel to the far end, what's stopping you >updating the /etc/fstab file? That I might do it wrong and end up with a machine that doesn't reboot properly. Thankfully it looks like we're going to need to install more memory in the machine, so I'll probably look to change things then, so if something goes wrong at least someone's there. But quite honestly, I still haven't seen anything that really justifies this change *needing* to be in -stable. So I've expressed my opinion that I think making the change there isn't the smartest idea in the world. Other people are certainly entitled not to agree with me, but last I checked there's nothing saying that I can't say that I don't feel this is in the best interest of people running -stable. Gary Schrock root@eyelab.msu.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803111753.MAA10778>