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.hoogl...@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" <da...@gnsa.us>: > >> On Wed, Apr 22, 2015 at 4:47 PM, Marcus <shadow...@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 >>
