Date: Sun, 10 Jun 2001 10:37:46 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Sheldon Hearn <sheldonh@starjuice.net> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc rc Message-ID: <Pine.NEB.3.96L.1010610103159.28120C-100000@fledge.watson.org> In-Reply-To: <3604.992174765@axl.seasidesoftware.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Jun 2001, Sheldon Hearn wrote: > On Sat, 09 Jun 2001 11:53:20 -0400, Robert Watson wrote: > > > Me, and the answer is no: RELENG_4_3 is currently reserved for security > > fixes only. > > How silly. :-) > > > And frankly, as well tested as the patch may have been, it would have > > hurt no one to wait 2 days to MFC those changes. The cost of screwing up > > the rc scripts (especially file system mounting) on -STABLE are pretty > > high: even if you feel the risk is low, a delay of two days is worth it. > > Fair enough. All I can say is that the rc scripts were _already_ > screwed up for anyone who might try to add smbfs automounts to > /etc/fstab. This fixes a problem. I recognize that it fixes a problem. But I also recognize that we have a stated policy of delaying MFC's at least a couple of days, even if there is no way they can possibly break anything. We have too many examples of that not being the case. > > Also, does your definition of remote file systems include Arla, Coda and > > AFS? Are you aware that both of those remote file systems require > > supporting daemons before they can be started, and those remote daemons > > aren't loaded until /usr/local/etc/rc.d/* have been executed? > > No. Both you and Garrett seem to think that I should back out this > small change that fixes a problem and that folks should wait for someone > (certianly not me) to fix several other problems first. > > I realize that the "leave it broken until we can fix it properly, even > if we have a partial fix available right now that isn't completely > evil" mindset is popular, so I'll back out the change. As I indicated to you in private e-mail, this was not a back-out request, it was a (a) That MFC was *way* too fast, and (b) have you kept the following in mind in your fix. > This whole problem would be mostly solved if people hadn't put up so > much resistence to NetBSD's new rc scheme, which is working very well > for them. I have not opposed this at all, and would be happy to see a more structured boot mechanism. > I'm happy to contribute work to the project, as long as the definition > of work doesn't include having to invest lots of energy in convincing > people that an okay solution is better than no solution as long as it > doesn't cripple development. I suspect that this perceived up-hill > battle puts quite a few people off contributing (I wonder if nbm is > reading this). :-) Well, it's fair to say that in any group project where everyone has time invested, you should expect to spend a certain amount of energy demonstrating that a solution is the right one: the tendancy is for solutions to not be "perfect" the first time around, because they reflect the needs of the individual contributor, and it's unlikely those needs reflect the needs of the entire developer and user base. That said, I think you misinterpret the thrust of my e-mail (or I express it poorly): my primary objection was not to the content, rather, the rapidity of the MFC. My question about the content was just that: a question as to whether you had taken into account a class of remote file systems regularly used on FreeBSD (likewise, CFS, etc), those that require a daemon to be running before they can be used. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010610103159.28120C-100000>