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 >
