cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [DISCUSS] 4.6 release management
Date Fri, 24 Apr 2015 17:56:27 GMT
On Fri, Apr 24, 2015 at 4:53 PM, Rohit Yadav <rohit.yadav@shapeblue.com> wrote:
> Daan,
>
>> On 24-Apr-2015, at 3:53 pm, Daan Hoogland <daan.hoogland@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

Mime
View raw message