I agree with everything being said, assuming it's a critical bug. Otherwise, the quality argument doesn't hold up, because it's otherwise a blanket defense for anything.
I'm just not seeing evidence that anyone running a cloudstack cloud for the last two years has cared or noticed that the time can get off sync in system vms, or that it has implaced functionality at all. Do we have bug reports, or is this one feature the sole thing that has made anyone notice? A bug that doesn't cause harm isn't critical, and in my perspective only impacts quality at an academic level. On Wed, May 22, 2013 at 10:23 AM, Outback Dingo <outbackdi...@gmail.com> wrote: > 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/ >>
