Joe, I just realized a dropped a sentence out by accident. I meant to add that this issue does not approach KDE 4.0 (they had literally 100s of issues), but they got caught up in the desire to get something out for world to see, and ended up harming their reputation. I am merely warning against getting on that slippery slope.
I apologize for the inadvertent hyperbole, -John On May 22, 2013, at 12:11 PM, Joe Brockmeier <j...@zonker.net> wrote: > 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/
