Michael Matz wrote: >> pressure build on some set of infrastructure until it has been painfully >> obvious for some amount of time that it has to change. (In my >> experience, the same thing happens in developing proprietary software; >> convincing product management to let you spend significant time fixing >> something that's not on the next release's feature list requires some >> good salesmanship.) > > How true :) Nevertheless the goals for the FSF GCC should IMHO be purely > based on rather technical arguments and considerations, not the drive by > paying customers.
Even when I was contributing purely as a volunteer, I had motivations of my own, like wanting to use a particular feature in a program I was writing. I don't think we can realistically expect that the SC can set up a master plan for everyone to follow. The SC or the maintainers are in my opinion completely justified in blocking the inclusion of a technically inferior patch, even if it has some short-term benefit. There's no reason that any contributor should get to jam in a patch that's going to make things hard for everyone else in future. So, I'm not arguing that "whoever gets there first wins", by any means. But, I don't think we can ignore the motivations of contributors, either; we've got to accept that they'll invest time/effort/money in GCC only to the extent they see return on that investment. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
