On Fri, Apr 24, 2015 at 4:53 PM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Daan, > >> On 24-Apr-2015, at 3:53 pm, Daan Hoogland <daan.hoogl...@gmail.com> wrote: >> >> Rohit, the issues you mention are not as painful if we release in a >> two week schedule as the period of creating a fix to seeing it in a >> release will be shorter. Some releases will be broken for some people, >> I don't think we can prevent this. The target we are aiming for is to >> big to cover it completely. > > I agree with you, but I think there are pros and cons to both approaches and > for this to work it needs to be able to walk first before it can run. > > For this to work we need an automated QA system, to solve this Abhi is > working on it for past few weeks and will be adding more non-hardware tests > (simulator ones) to travis. In my free time, I’m trying to setup a nested > virtualized environment where we can test ACS against Xen, KVM and VMware on > top on KVM. So far, I’m able to run XenServer 6.2+6.5 and KVM on top of KVM > with vmx (intel-vt) enabled, and making some progress with running ESX on KVM > (I’m able to run ESX 6.0 on KVM now, but not ESX 5.x which is something I’m > exploring). I hope we'll have something working soon that is fairly fast and > easy to reproduce.
Fred Neubauer, a Schuberg Philis colleague has just finished creating a bubble for testing and development purposes. It looks really good. We are underway to create a new style jenkins slave in which multiple hypervisors, management servers and db servers can be created. Sounds like you are at the same point then. All that we are discussing here is of varying distance in the future. Let's not forget this in the discussion. In the end ideal would be continuous delivery for all cloudstack installs;) > >> Your points are valid, though. >> .1 a three person release team makes sense. I have been really happy >> with the help I got from Pierre-Luc and I think David can do with help >> the coming time as well. >> .2 Hopefully people won't need to test every release so extensively >> anymore as the changes become smaller. (and my initial remark the >> above applies as well) > > By having too many releases we’ll have to deal with too many upgrade path > issues and users will spread across different versions which will create an > issue for maintainers who are supporting users -- one solution for this > problem can be that we introduce a concept of LTS release that is either > maintained by the community (which can be difficult) or some interested > stakeholders, for users that would prefer upgrading everytime there is a new > CloudStack release. Database upgrades need fixing. When we think on this all relevant scenarios need to be considdered; slow following users, bleeding edge users and developers. LTS in combination with forward merging of fixes seems to be the way to me. (as often said, not just by me;) -- Daan
