On 8/15/2018 3:47 PM, melanie witt wrote:
I think part of the miss on the number of approvals might be because we
extended the spec freeze date to milestone r-2 because of runways,
thinking that if we completed enough things, we could approve more
things. We didn't predict that accurately but with the experience, my
hope is we can do better in Stein. We could consider moving spec freeze
back to milestone s-1 or have rough criteria on whether to approve more
blueprints close to s-2 (for example, if 30%? of approved blueprints
have been completed, OK to approve more).
If you have feedback or thoughts on any of this, feel free to reply to
this thread or add your comments to the Rocky retrospective etherpad [4]
and we can discuss at the PTG.
The completion percentage was about the same as Queens, which is good to
know. And I think is good at around 80%. Some things get deferred not
because of a lack of reviewer attention but because the contributor
stalled out or had higher priority work to complete.
We approved more stuff in Rocky because we had more time to approve
stuff (spec freeze in Queens was the first milestone, it was the second
milestone in Rocky).
So with completion rates about the same but with more stuff
approved/completed in Rocky, what is the difference? From a relatively
intangible / gut feeling standpoint, I would say one answer is in Queens
we had a pretty stable, issue free release period but I can't say that
is the same for Rocky where we're down to the wire getting stuff done
for our third release candidate on the final day for release candidates.
So it stands to reason that the earlier we cut the approvals on new
stuff and have more burn in time for what we do complete, we have a
smoother release at the end. That's not really rocket science, it's
common sense. So I think going back to spec freeze on s-1 is likely a
good idea in Stein now that we know how runways went. We can always make
exceptions for high priority stuff if needed after s-1, like we did with
reshaper in Rocky (even though we didn't get it done).
--
Thanks,
Matt
__________________________________________________________________________
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