On Wed, 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. > > The quality of software and its new feature sets, if supported should all fall in parity with supported platforms The fact that 1) this is a critical bug, 2) it affects the entire XEN/XCP base, 3) has been known and not resolved While being at a senior level management position running an R&D team, I would always tell the CTO/CEO If its not fully baked and QA's its not ready to come out of the oven. Push the date. Id rather see CS as a whole remain in feature parity and crush this last critical bug then push out a release, and discourage any XEN/XCP environments from looking at moving forward with the software stack as a whole. I wouldnt do it to clients, I feel we shouldnt do it to our users. resolve the problem, and QA it, then move forward, dont bandaid it, dont neglect it if others are so gung ho to user 4.1 before its released they can build from source, there are options for moving forward, leaving this stone unturned i feel would be detrimental to the good reputation Cs had enjoyed. I usually say much, until I feel strongly about an issue. But I ask, have we even really assessed what it will take to fix, instead of just throwing it to the wolves to vote on? will it take a week, to resolve and test. If we cant answer this question, then we shouldnt even be having the voting discussion, let alone how longs it been a "known" issue, regardless of who noticed or who it affected, the fact is someone noticed it, otherwise there woulnt be a bug report on it. so we just answered logically who noticed, someone did, whos it affect, well obviously it did affect someone. fix it, qa it, release and moved forward before we get to far down the road and its harder to resolv. > Best, > > jzb > -- > Joe Brockmeier > j...@zonker.net > Twitter: @jzb > http://www.dissociatedpress.net/ >
