Release Cycle Observations
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 . 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  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.