On 9/26/2019 8:38 AM, Donny Davis wrote:
Can the release cycle be modified to ease this push at the end? I think what we all want is a smooth and steady stream of features and bug fixes, but a 6 month release cycle seems to do directly the opposite. Also if everyone has gate issues at the end of the cycle, is it the gate or the cycle? The gate seemed to work fine early on...
Oh lordy, you've started *this* thread again. :P Yes this has come up many a time and Clark replied about gate issues - they are always there but people care less because there is time to recheck earlier in the cycle. In nova we've historically tried all sorts of different tricks to try and manipulate the schedule within the 6 month cycle, like priority vs non-priority spec and feature freezes, runways, etc, because no matter what we do, the most code and review velocity kicks in about 2 weeks before a deadline. Changing the release cycle isn't going to change the human nature about that. People are still going to wait until too late in the cycle to focus on their complicated feature, and reviewers are going to wait too long to get serious about reviewing the more complicated features. The runways concept is meant to help with that so once a blueprint is ready for review it's in a 2 week queue and contributors can expect to get core reviews, but not all features are the same or get the same interest from the core team, so it has it's pitfalls. Maybe people don't want to admit it, but this is a corporate driven project so a lot of the time money talks so people are going to spend time on what their employer wants them to spend time on, which might not be aligned with "the good of the project" or some lower priority feature that someone else wants to get in. In last week's nova meeting we also talked about some of this [1]. If you change the release cycle to do major and minor versions, that's going to be pretty complicated for testing upgrades, because grenade goes from major to major based on branches. We could probably make it work (and maybe it's already possible, I don't know to go from tag (minor release) to master, but the point is you're going to blow up the upgrade test matrix and it's not clear anyone is even going to be consuming those minor intermediate releases. I think this is partly why the release team stopped doing a cycle-with-milestone [2] release because no one was consuming the milestone releases. Anyway, if there is some magic bullet for reducing noise and increasing focus on what we think is most important to merge in a release I don't think we've found it yet even though we've talked about this many times for many years. [1] http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-09-19-14.00.log.... [2] https://releases.openstack.org/reference/release_models.html#cycle-with-mile... -- Thanks, Matt