Chris Bowditch wrote: > ideas because they didn't yield 100% compliance. Regardless, > my main point in this thread was simply that compromise is > the key to getting to a release. Which is one of your points > above, right?
Not really. I agree with the importance of getting along where possible, but compromise is a relatively unimportant piece of that. Far more important is building, by persuasion and sound reason, *unity* within the team about the direction of the project. The willingness to compromise, to yield on relatively unimportant issues for the sake of the bigger issues, implies a level of unity about the bigger issues. Compromising on pragmatic issues is important and useful, compromising on fundamental issues is suicidal. Now, I think FOP has a fair amount of unity right now, and I am glad for it. WRT 100% compliance, you do not have to achieve 100% to make something useful. (However, I will argue that you should not call something 1.0 until that is achieved). But the important issue is whether your basic design will allow you to eventually get to 100%. If you lock yourself into a design that will *never* get you to 100%, then you mandate another rewrite. So yes, I think it is a duty for any FOP developer to speak up when he sees that kind of situation arise. And yes, I think it would be unwise to compromise on such a matter. So, no, I did not mean to imply that "compromise is the key to getting to a release." I am sorry for that this discussion became inflammatory. I thought my original comments were innocent enough, but it is clear that I should not have made them. Victor Mote
