On Feb 24, 2015, at 1:50 PM, Joe Gordon <joe.gord...@gmail.com> wrote:
>> I think the release candidate >> period is the only thing that makes your code drops actually usable. >> It's the only moment in the cycle where integrators test. It's the only >> moment in the cycle where developers work on bugs they did not file >> themselves, but focus on a project-wide priority list of release >> blockers. If you remove that period, then nobody will ever work on >> release blockers that do not directly affect them. Shorten that period >> to one week, and no integrator will have the time to run a proper QA >> program to detect those release blockers. > > I still think the 3 week RC candidate cycle needs to happen, the difference > is it would be done by stable maintenance. And I agree, the RC candidate > period is one of the few moments where developers work on bugs they did not > file themselves. So I am not sure how this would actually work. Perhaps the > answer is we have deeper issues if we don't want to fix bugs until the last > minute. I like the notion that there isn't an overall release that all development is tied to, but that at some more or less regular interval, a new stable "release" is cut, and intense integration testing is done on that, with bug fixes as needed. But how to get developers who are intent on coding their new features to hold off and work on fixing bugs identified by the stable testing is a big question mark to me. -- Ed Leafe
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
