Date: Mon, 31 Aug 1998 23:25:22 +0000 From: Mike Smith <mike@smith.net.au> To: Bob Vaughan <techie@tantivy.stanford.edu> Subject: Re: Looking for feedback on xl (3c905/3c905B) driver Message-ID: <199808312326.XAA01271@word.smith.net.au> In-Reply-To: Your message of "Mon, 31 Aug 1998 22:54:15 MST." <199809010554.WAA04982@tantivy.stanford.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
(Bob, please forgive me for copying -stable on this; you raise a couple of points that are worth responding to in public as they're applicable to the discussion in general.) > I guess the other half of the point isn't quite making it thru.. > > Bill's request for feedback was the FIRST time I had heard anything about > a change in the vx driver, other than the fact that a new driver for the > 3c90x series was being written. In case you didn't notice, this notice came > a week after the change had been committed. You're quite correct, and my recollection is wrong; there wasn't an announcement on -stable. I'm sorry for the error there. > I don't expect to be talked down to like a schoolboy, especially when I > have been doing everything that it was suggested I do. So you've been reading the commit messages, then? I'm sure many people have recommended this before. Seriously; if you really want 100% coverage, you have to watch *everything*. As I tried to point out before, it's quite difficult to ensure that all of the possible consequences of a series of changes are explained *before* the changes are made, and that people will understand the explanations. For a good example of this in action, see the ELF transition process as it's currently being discussed on -current. Despite literally weeks of pre-release testing, exhaustive instructions, documentation out the wazoo, there are still problems being encountered across a range of cases from "user ignored instructions" to "everyone scratching their heads". To do better than we try to do now would involve forcing developers to hold back for some period (which would never be long enough) between deciding to commit something and actually doing it, so that the effects of the change could be documented, disseminated, explained, etc. This is something that can be done inside a formal development framework, but it's much harder to impose this sort of discipline and management-level control on a group of volunteers. Instead, we encourage committers to try to assess the effects of their changes, and to publicise these where appropriate. This is always the commit messages for the code in question, and generally also the list corresponding to the branch (current, stable, small, etc.). Sometimes this doesn't happen, and we get a situation like now. > I don't expect anybody to hold my hand, but I do expect at least some > notification of major changes, before I run into them. I think it's clear now that we slipped on this. What can I say? > we got plenty of warning when the slice code changed, it would be nice to Don't make me laugh; I flubbed that one too. 8( -- \\ 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?199808312326.XAA01271>