I agree with that, there are regressions occasionally with bugfixes, but I generally don't see any obvious distinction made in the voting thread. Someone finds a problem, they want to patch it, others are found, we roll a new RC.
On Wed, Apr 22, 2015 at 3:49 PM, David Nalley <da...@gnsa.us> wrote: > 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
