see inline
On Jan 7, 2016, at 3:39 PM, Nux! <n...@li.nux.ro> wrote:

> Hi,
> 
> 
>> So, yes, monthly releases can be done and the quality is better than before.
>> Actually, I think we should go much faster. Whenever a PR is merged that 
>> fixes
>> your issue, it should be possible to deploy it right away. It’s a change in
>> mindset.
> 
>> 
>> 
>> Let me know!
> 
> Ok, so first of all I am letting you know that I appreciate your efforts very 
> much and can't thank you enough for your being RM. 
> Also a lot of thanks to other SBP staff, PCExtreme, Leaseweb & Shapeblue and 
> others for all their work; sometimes I just feel like a scavenger, 
> "profiting" from their work. :)
> Keep up the good job!
> 

+1000

CloudStack is in its best shape ever indeed due to the hard work from Remi, 
Wilder, Daan, Rajani, Wido and a few others that I am missing.

It is also in its best shape ever because we moved from developing on master 
and GA'ing a release branch over several months.

We know have a stable master that also has the latest features and fixes.

> Secondly, my own problem with the current velocity is that it does generate 
> fatigue.
> Everything must be tested all the time, eyes must be on git and on the 
> mailing list. 
> 

The way I see it we completed the first phase of a big change for us. We 
changed our release process.

This has led us to this amazing place:

Today we can release production ready CloudStack *at any time* in 72 hours (the 
time to close a vote), it's terrific.

The other side of the coin is that we can release so often we need to change 
our mindset and doing so be mindful of folks that are used to the old release 
pattern.

Clearly we cannot keep maintaining all release branches, we used to say that we 
would maintain the last two major and the last minor.

Yet folks (like Rene) may like a pattern of just minor and very infrequent 
major. While folks like Remi want continuous deployment.

So at the cost of sounding a bit "fatherly" we indeed need to discuss this a 
bit. I mentioned it after 4.6, and communicate clearly to everyone how this 
works.

Keeping in mind that we don't want to abandon anyone and we want everybody to 
be able to upgrade easily.



> And this is how it should be, really, but it can become a problem or at least 
> disappointing when people fail to engage as much as we'd want.
> We need to be aware the community is indeed small, the users might be many 
> but few get involved in development (people still don't get "open source") 
> and not many of us have the luxury of 
> working with Cloudstack every day and have it be the main subject.
> There are days when I don't even get to think about it, let alone do anything 
> about it, I work some very busy shifts dealing with random things.
> 
> I think people in my situation - or worse - might feel uncomfortable with a 
> fast pace, they might feel left behind and sometimes it's just not easy to 
> keep up. 
> I know how heavy it feels to run a mission critical cloud and have no idea 
> whether you'll be able to pull the next upgrade off.
> The idea of longer term support through many minor versions can sound very 
> appealing and make people feel cosy. RedHat is exploiting exactly this with 
> their RHEL, for example.
> 
> Having said that, I would not go back to the old ways. I think we're on a 
> good track here and we just need to test more, especially automate said 
> testing more, in environments as close to production as we can. This my 2016 
> resolution. :-)

+1000 here.

We are on a great track. Let's keep refining our process, complete the second 
phase which is proper CI ,  agree on how to move forward and communicate on 
which releases are maintained and for how long.

> 
> My 2 pence
> 
> Lucian

Reply via email to