Date: Wed, 11 Mar 1998 03:25:20 -0800 From: Mike Smith <mike@smith.net.au> To: Gary Schrock <root@eyelab.psy.msu.edu> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: *HEADS UP* Correction to previous postings. Message-ID: <199803111125.DAA22879@dingo.cdrom.com> In-Reply-To: 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
> This is making me very concerned. We get about 3 hours warning on this, > and are told that for the time being as long as you update mount you > shouldn't have problems. Then later we get corrections to who this change > really affects. How well tested is this change? 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. > How do I *know* I'm not > going to have problems because something might have been missed? Nothing in life is certain. If you depend on the reliability of your systems, you will install on a test system before deploying. > For that > matter, why did this need to be put in freebsd-STABLE instead of current? > To me it makes more sense to have put it there, because at least there one > expects changes that might break things. 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. > I also find the attitude about people who have to do remote updates a bit > disconcerting. Some of us have no choice. When your machine exists by the > grace of the people at the other end, and you have to pay obscene rates to > get someone to do work on it if something goes wrong, you have a right to > be concerned about how this will affect things. Not everyone can have > someone local to the machine that's available to go in if something gets > screwed up. In our case, the closest person to the machine is a couple > hours away, and can only get in during regular business hours, a time which > when he's busy at his regular job. 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 can't actually imagine deploying the most-recent release of *anything* in a mission-critical remote site; I'm not sure how I can politely tell you that no matter what guarantees we might try to offer, that's a recipe for heartache. > How long is the backwards compatability going to be in? Can we at least > assume that it won't be removed in the life of 2.2? If I don't have to > worry about the compatability disappearing in 2.2, then I can safely just > leave it in until we have a time when we can get someone to go to the > machine in case something happens. 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? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199803111125.DAA22879>