Open Stack

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.html#l-152
[2] 
https://releases.openstack.org/reference/release_models.html#cycle-with-milestones-legacy

-- 

Thanks,

Matt