On Wednesday 02 February 2011 21:15:31 Aaron J. Seigo wrote: > On Wednesday, February 2, 2011, Thiago Macieira wrote: > > I still think the current procedure is wrong. You're not testing the > > stable release, there's no guarantee that you're solving the problem at > > all, or worse, that you're not making it worse. > > and, imho, the stable branch is the more important thing to test: if it > goes wrong in master due to a bad or unecessary merge from stable, you > usually have months to notice and fix it. certain you or your teammates > that also track master will notice it faster than if it sits in the stable > branch where primary devel isn't happening anymore. with our monthly x.y.z > releases, you have at most a few weeks with fewer people tracking the > stable branch to catch a bad merge from master. > > so, again at least imho, the risk is higher when backporting compared to > forward porting. > > and finally we have a tool that makes it reasonably painless to do it. :)
I have two reasons to test in master: - I run master myself all the time. - If a fix really is dangerous I don't want it to appear in a bugfix release "by accident". If nobody was running master who'd make sure its quality was even remotely decent? Somehow I don't buy that we should all be testing the latest stable branch while developing against master. Switching environments all the time is a major hassle and not as effective at finding and making people care about bugs in master.
