On Wed, Jun 8, 2011 at 6:43 PM, Joshua Berkus <j...@agliodbs.com> wrote: > Simon, > >> The point I have made is that I disagree with a feature freeze date >> fixed ahead of time without regard to the content of the forthcoming >> release. I've not said I disagree with feature freezes altogether, >> which would be utterly ridiculous. Fixed dates are IMHO much less >> important than a sensible and useful feature set for our users. > > This is such a non-argument it's silly. We have so many new major features > for 9.1 that I'm having trouble writing sensible press releases which don't > sound like a laundry list.
You're right this is a non-argument. I am not continuing this debate using the above point. I am merely correcting people's assertions about what I think, which is a little tiresome for all of us and it would be much better if people didn't foolishly put words in my mouth, as multiple people have done on this thread. I'm also quite happy with the feature set for 9.1. >> MySQL >> repeatedly delivered releases with half-finished features and earned >> much disrespect. We have never done that previously and I am against >> doing so in the future. > > This is also total BS. I worked on the MySQL team. >Before Sun/Oracle, MySQL specifically had feature-driven releases, where >Marketing decided what features 5.0, 5.1 and 5.2 would have. They also >accepted new features during beta if Marketing liked them enough. This >resulted in the 5.1 release being *three years late*, and 5.3 being cancelled >altogether. And let's talk about the legendary instability of 5.0, because >they decided that they couldn't cancel partitioning and stored procedures, >whether they were ready for prime time or not and because they kept changing >the API during beta. > > MySQL never had time-based releases before Oracle took them over. And Oracle > has been having feature-free releases because they're trying to work through > MySQL's list of thousands of unfixed bugs which dates back to 2003. I claimed they delivered half-finished features. You clearly agree with me on that. I'm not sure which part you see as BS? > An argument for feature-driven releases is in fact an argument for the MySQL > AB development model. And that's not a company I want to emulate. Yes, I've also experienced totally marketing-driven software development, and that's why I'm *here*. I've spoken at length about how good our process is and have considerable respect for it and the people that have made it work. I am not advocating any changes to it at all, especially not to the model used by MYSQL AB. I have asked that we maintain the Reasonableness we have always had about how the feature freeze date was applied. An example of such reasonableness is that if a feature is a few days late and it is important, then it would still go into the release. An example of unreasonableness would be to close the feature freeze on a predetermined date, without regard to the state of the feature set in the release. To date, we have always been reasonable and I don't want to change the process in the way Robert has suggested we should change. I was one of a number of developers making that point at the developer meeting and I would say I was part of the majority view. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
