On Thu, 14 Jun 2001, Matt Dillon wrote:
>
> :
> :On Thu, 14 Jun 2001, Matt Dillon wrote:
> :
> :> My advise: First make it work. THEN make it work better.
> :
> : Excellent advice, as long as you don't skip the steps of
> :appropriately defining the problem domain and evaluating all of the
> :possible solutions for it.
>
> Well, now mind you I am not arguing with you specifically,
It's ok, I have a thick skin. :)
> but I will
> point out that you might garner a great deal more input into the project
> if someone does a good first-run port of the NetBSD stuff and actually
> gets it into the tree as an alternative, even if it isn't 100% perfect.
This is exactly the approach I want to avoid. The reason being
that we saw in the /dev/random development cycle how much intertia, and
just plain BS has to be overcome to make any kind of major architectural
change, and this is a change far exceeding that one in depth and scope. I
am resolved to live through N amount of whining when the changes happen, I
don't think it's healthy to ask either the project at large or the people
doing the new rc system to live through N x 2, or more. I agree that it
doesn't have to be perfect before the first commit, but I'd like to see
the big questions answered before real work starts, and a fairly solid
framework in place before we ask people to gamma test on a live -current.
Think first, code second, think some more is my motto.
> I was thinking of something along the lines of an rc.conf variable that
> causes /etc/rc to use the new system rather then the old.
This is a truly excellent suggestion, thank you.
--
If you're never wrong, you're not trying hard enough.
Do YOU Yahoo!?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
