On Wed, May 22, 2013, at 10:51 AM, John Burwell wrote: > I would say that the only thing for an open source project worse than not > releasing is releasing a poor quality release. A late release with high > quality is soon forgotten. An on-time or late release with poor quality > lingers in folks memory. The KDE project made the near fatal mistake of > following the same logic when they release 4.0, and the reputation of KDE > 4.x continues to suffer from it to this day. CloudStack is trusted to > run at the core our user's operations. In my view, if we err, we should > err on the side of quality to avoid of erosion of that trust. If we ever > lost that trust, our new features would never be evaluated.
I'm not sure this issue approaches KDE 4.0 levels, but otherwise +1. (Note - the KDE folks are *very* touchy about 4.0 *still* being held up as a high-water mark of poor judgement in releases, which is in and of itself a cautionary tale for releasing something that's not ready...) Why are users waiting for us to officially release instead of grabbing artifacts from Jenkins? In large part, they're waiting for the project to "bless" the quality of the release by saying it's ready. Time-based releases are supposed to be a way of ensuring that we don't hold up releases indefinitely because of missing features - but I don't think that extends to knowingly releasing something that is a pretty serious bug. Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
