cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <run...@gmail.com>
Subject Re: Next ACS release?
Date Thu, 23 Apr 2015 07:17:00 GMT
Folks, great discussion. I am on vacation, so not ignoring.
Will chime in when i return.

-Sebastien

> On 23 Apr 2015, at 09:57, Daan Hoogland <daan.hoogland@gmail.com> wrote:
> 
> Paul,
> This will be interesting:
> "I'm also going to compile a list of people who vote "+1 - it works on my
> laptop" and devise a Guinness related punishment for any of them that show
> up at the CloudStack day in Dublin."
> 
> Why don't you start on list and see how this improves test quality.
> 
> I agree wiith David on the harm bugfixes. can do. The two week cycle is
> ment as a moment for initializing a bf rc, not all of them have to make it
> or be deemed necessary.
> 
> mobile dev with bilingual spelling checker used (read at your own risk)
> Op 23 apr. 2015 00:50 schreef "David Nalley" <david@gnsa.us>:
> 
>> On Wed, Apr 22, 2015 at 4:47 PM, Marcus <shadowsor@gmail.com> wrote:
>>> We just have to do it.  We just freeze master at some point, do all of
>>> the release bugfixes, and when it is solid enough to pass a release
>>> vote we branch a release from it, and then only allow merges to master
>>> that have been tested in a merge branch, or something along those
>>> lines. Things will slip through, because our testing isn't full
>>> coverage, but we can begin to add to it.
>>> 
>>> I've said it before, but I think we're also a bit stingy regarding
>>> bugfix releases. Unless we cause a regression, there should be no need
>>> for bugfix releases to go through multiple RCs. We get caught on bugs
>>> that are already in the shipping version and make them blockers for
>>> the other bug fixes, or a pet patch needs to slip in (which also only
>>> matters because bugfix releases are so few and hard to release).
>>> 
>> 
>> It's not just new features that cause problems though.
>> We've had bug fixes that cause issues, sometimes worse than the one
>> they solved. Every change is a threat to stability, so we'd like to
>> have smaller bug fix releases too. There's an inherent cost in doing
>> releases in their current form.
>> 
>> --David
>> 

Mime
View raw message