Date: Wed, 12 May 1999 14:53:31 -0700 From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> To: Noriyuki Soda <soda@sra.co.jp> Cc: dfr@nlsystems.com, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pcisupport.c Message-ID: <66043.926546011@zippy.cdrom.com> In-Reply-To: Your message of "Wed, 12 May 1999 18:26:45 %2B0900." <199905120926.SAA19601@srapc342.sra.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> I agree that this is better way to solve the conflicts between new-bus > and newconfig. Although I wondered why FreeBSD's core decide to choose > new-bus before Usenix. We didn't choose it "before USENIX" as if it were somehow part of the objective to get this feature in before a public event, it simply came up that Peter had the time to actually integrate new-bus from the Alpha platform to the x86 and it was deemed desirable to have the SAME bus configuration code for both architectures. I don't see how any engineer in his right mind could argue that it made sense to have two, active and shipping ports to different architectures, each with its own bus code. Whether new-bus or newconfig is "better" was really, honestly not the issue so much as were the following two bullet points: 1. Does this bring the alpha and x86 architecture ports into better alignment so that any future permutations can be more easily brought across and/or simply shared between the two platforms? 2. Have we had a good history of communications between the people doing new-bus vs our history of communication with the newconfig people? The latter point is actually *really important* since we've already learned that having totally separate groups who talk to us maybe once a month (if even that often) is just not a workable strategy for the long term and often causes more confusion for our users than it actually helps the project. We talk to Doug Rabson on a practically daily basis on a wide variety of issues whereas the only real communication I've seen from you has been during this conflict. Before that, I had no idea that a Noriyuki Soda even existed. :-) This project essentially lives and dies by the strength of its "ties" to various developers. Given the fact that one body of code came from someone whom I *knew* we could work with, given a long history of working with them, and the other body of code came from someone who really only became known to myself and the rest of core when we saw your paper submission for USENIX (which I'm looking forward to attending, as I'm sure are many others in this discussion), well, it really wasn't a hard decision to make at all. Given the same set of factors, we'd make the very same decision today. To try and put it another way, I've seen a lot of arguing about the technical merits of the two systems but very little arguing about how to solve the HUMAN FACTORS aspect of this situation which are really and truly what led up to the core team's decision. I've also called for greater communication between the two groups and so far all I've seen is a lot of arguing and expressions of general annoyance from Japan - that is NOT communication! Proper communication involves regular discussion about incremental improvements to the code base and how best to carry them out, biting off problems in small chunks and dealing with each completely before moving on to the next. Simply wandering off with the entire problem for 6 months and working on it in isolation DOES NOT WORK and we've proven this again and again. It only leads precisely to the situation we have here now with newconfig and also PAO. To put the problem in a larger context, people often ask me what all the FreeBSD people in Japan are working on and it's a point of eternal embarassment to me that I usually have to say "I honestly have no idea." Many of the various developers in Japan really don't go much out of their way to let me or core in general know what's going on (though there are some notable exceptions) and it's like working in a company where a major part of it is entirely off-site and never calls you on the phone; anyone who's actually worked in such an environment knows exactly what I'm talking about and can appreciate the frustration of not knowing what a good chunk of your organization is up to. We really really really need to fix this if we're to avoid further repetitions of this kind of thing and that's why I'm flying to Tokyo at the end of this month to talk with you guys - we're clearly not communicating adequately and I'm willing to do what I can, including physically relocating myself on a periodic basis, to fix it from this side. What are you doing to fix it on yours? :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?66043.926546011>