Hi folks, One of the things I've been pondering of late is a set of release criteria. E.g. here is what CloudStack MUST do to be considered for release.
So as background there is a somewhat complex social contract that I think we informally enter with our users. People expect us to release when we project - and we (IMO) damage the credibility of the project by suggesting a date and then missing, sometimes by a wide margin. In reading some of the documentation that other folks have around Time-based releases, I really like one of the analogies that Ubuntu uses [1] which is that of a play in a theatre. Things may not be perfect, people may not absolutely know all of their lines, but tickets have been sold, the audience is standing outside waiting to come in, and it's a pretty drastic event for the show not to go on. At the same time, bringing multiple RCs forward which get voted down doesn't necessarily inspire confidence. Some of this is caused by our lack of comprehensive testing. I think many people have an innate sense of what they think CloudStack should deliver in a product release; but we also have a number of people who suggest that they are timid in signing off on a product release simply because of the scope. I think we should actively be setting the expectations of consumers of our product. Particularly in the short term when we don't have completely comprehensive testing, having a standard that we can test to that is our 'minimum acceptable' makes sense in my mind. I am going to spend a few days drafting a set of criteria, and I'll post it to the wiki, and ask for feedback and help in refining it, just wanted to give a heads up on what I am thinking, and hopefully get some consensus around it being a worthwhile thing. --David [1] https://wiki.ubuntu.com/TimeBasedReleases
