I've repeated it several times in other threads, but I think at a bare minimum it has to work in the listed versions of Ubuntu, CentOS (both mgmt server and KVM host), XenServer, VmWare, what have you, along with the advertised storage and networking. We can discuss limiting that to OSS, maybe, as a languishing third party plugin shouldn't hold us up, and if it's languishing and OSS we should perhaps consider deprecation. As seen in 4.2, we need to also make sure that upgrades work according to a defined matrix (supported upgrade compatibility has been discussed recently on the list as well, it has been a few months). If we can test those things and pass before we cut an RC and begin voting, I think we will be in far better shape than we have been, from what I've seen. Maybe we don't stop there, but it seems like a good place to start and basic enough to be doable. Maybe we boil it down to a dozen or so checkboxes, being each supported platform can successfully deploy a zone with one VM, each supported storage type can deploy an instance, each of the supported upgrade paths work. And beyond that, if there are bugs, they'll be addressed in subsequent bugfix releases, but only things that affect those core items are blockers.
On Wed, Sep 11, 2013 at 9:52 PM, Alex Huang <alex.hu...@citrix.com> wrote: >> > >> > A broken master also slows down other devs. I can't remember the >> number of times I've been debugging master for hours to find out something >> broke it. >> > >> >> so how do we enforce this ? >> > > I'm so glad we raise this point. For some time now, Prasanna, Amogh, Frank, > and a number of others have been working on getting continuous integration > working on CloudStack. I've mentioned it before but because of the releases, > the work's been delayed. I think they are pretty close now so I like to > propose it here. > > I've talked about it on here [1]. What do everyone think? I specifically > left out the bits about whether we should use gerrit. That's more which > system we use to implement the review part but I think we should get to the > point where no matter who it is, their checkins are not committed to the > master/release branch unless it has passed BVT/Regression tests. That's the > only way to ensure that master is always stable. > > --Alex > [1] > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Automated+Tests+Rules+and+Guidelines >
