Hi, On Mon, 14 Aug 2006, Mark Mitchell 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. Normally we have the maintainer concept to guarantee some sort of that. This obviously creates conflicts when maintainers having to accept the solution and developers creating that solution (for customers or driven by own demand doesn't matter) are the same people. I think if in doubt the maintainer hat should win and I realize this is sometimes difficult (because the danger is that a feature will not be implemented at all if the customer isn't paying the cleanup, but the cleanup is the prerequisite to accept the feature). I have no good solution for this, but I feel that rushing things in because of customer milestones or deadlines is the wrong thing (I'm not accusing you of rushing things). Especially if most of the involved people agree on what is optimal on a technical basis nothing should prevent that from becoming implemented. Ciao, Michael.
