> One problem on the decision is that it was not based > on a judge that new-bus is technically or philosophically > superior to newconfig framework but you stated
I don't think they're so far apart that there's a "clear" superiority, and we certainly didn't get that impression from any of the discussions we saw between you guys and the new-bus folks. All I saw were some strong differences of opinion being expressed and a good chance that "superiority" would never be objectively determined by any of the parties involved. > Nakagawa would not be so upset if you could convince him > that new-bus were superior. Again, this appeared to be a matter of fierce argument more than anything else and I'd probably be just as inclined to try and get a Mercedes owner to agree that BMW made a "superior" car when, in fact, both vehicles provide a more than adequate ride and have a number of nice features. Given that neither system is exactly standing still, it also meant that relative superiority was a constantly changing factor and even though it might have been possible to say that newconfig was superior on one month, it would be by no means assured that this would remain a constant. What it ultimately came down to, as I said before, was choosing the group we had the best communication with and had some existing precedent, in new-bus's case that being FreeBSD/alpha. We learned a lot of painful lessons from the PAO project given the difficulties we've had with integrating that technology on an ongoing basis, and those are lessons we had no wish to learn again. Judging superiority is only partially a technical issue, and there are many other factors of equal importance when you start discussing projects of long-term significance to FreeBSD. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message