On Thu, 13 May 1999, Noriyuki Soda wrote: > This doesn't answer my wondering. The core members can safely postpone > the decision after Usenix, because all of core members must know that > both new-bus people and newconfig people will come to Freenix track. > Who is the chair of Freeunix track ? :-) > > > Whether new-bus or newconfig is "better" was really, honestly not > > the issue so much as were the following two bullet points: > > Quite interesting. This means that FreeBSD doesn't choose technology > by it's design, but by which spokes loudly. I definitely say that this > is worst way to design software.
I have to comment on this, it's too outrageous. Several times in the past, folks have written in and asked, if they wrote some particular piece of software, would it get committed. They said that it was a large undertaking, and that they wouldn't undertake it, unless there was general agreement beforehand about it. This has always had one response. No. We don't give apriori blank check agreement to stuff like that, because we don't know which way it's going to go, and if the final product isn't going where the developers (which means generally core, but not completely) then it's gong to be rejected. This has caused bad feelings sometimes, but it's stopped some folks from trying to hi-jack FreeBSD, and force it to go where one person wants it to go; it forces FreeBSD to be a group decision. So, how do big projects get done, then? The first point being brought up is true, no one wants to invest hugely in a project, just to see the work rejected. The way we get around that is by communicating, regularly and thoroughly, about the design and implementation of the project. Good communications means that we don't get into fights, and FreeBSD goes where the group wants it to go, not where some small set of interests want to hi-jack it. I am NOT saying that you or your group want to hijack anything, but the process DOES stop folks from doing that, and it's in fact already stopped that from happening more than once in my memory. Communications is a good thing, not something to be embarrassed about. Describing communications as "by which spokes loudly" is missing the point. Loudness hasn't the least to do with it. Regularity and clarity, getting the message across, is what's important. That is where your group has misunderstood the process. By going off on your own, and doing all that coding without any input, you established a reputation for not being willing to work together. Someone with a proven track record of communicating regularly was chosen. Not from a technical standpoint, but from a managerial standpoint, why does this surprise you? Don't offer technical arguments, this is not a technical issue. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
