Open Stack

Hey

Well, it definitely seems like there's not much support for the idea ;)

Thanks everyone who replied. I'll go away and think about ways we can improve things without moving FF :)

Cheers,
--
Chris Jones

> On 18 May 2017, at 11:18, Thierry Carrez <thierry at openstack.org> wrote:
> 
> Chris Jones wrote:
>> I have a fairly simple proposal to make - I'd like to suggest that
>> Feature Freeze move to being much earlier in the release cycle (no
>> earlier than M.1 and no later than M.2 would be my preference).
>> [...]
> 
> Hey Chris,
> 
> From my (admittedly too long) experience in release management, forcing
> more time for stabilization work does not magically yield better
> results. There is nothing like a "perfect" release, it's always a "good
> enough" trade-off. Holding releases in the hope that more bugs will be
> discovered and fixed only works so far: some bugs will only emerge once
> people start deploying software in their unique environments and use
> cases. It's better to put it out there when it's "good enough".
> 
> So a Feature Freeze should be placed early enough to give you an
> opportunity to slow down, fix known blockers, have documentation and
> translations catch up. Currently that means 5-6 weeks. Moving it earlier
> than this reasonable trade-off just brings more pain for little benefit.
> It is hard enough to get people to stop pushing features and feature
> freeze exceptions and do stabilization work for 5 weeks. Forcing a
> longer freeze would just see an explosion of local feature branches, not
> a more "stable" release.
> 
> Furthermore, we have a number of projects (newly-created ones that need
> to release early, or mature ones that want to push that occasional new
> feature more often) that bypass the feature freeze / RC system
> completely. With more constraints, I'd expect most projects to switch to
> that model instead.
> 
>> Rather than getting hung up on the specific numbers of weeks, perhaps it
>> would be helpful to start with opinions on whether or not there is
>> enough stabilisation time in the current release schedules.
> 
> Compared to the early days of OpenStack (where we'd still use a 5-6-week
> freeze period) our automated testing has come a long way. The cases
> where we need to respin release candidates due to a major blocker that
> was not caught in automated testing are becoming rarer. If anything, the
> data points to a need for shorter freezes rather than longer ones. The
> main reason we are still at 5-6weeks those days is for translations and
> docs, rather than real stabilization work. I'm not advocating for making
> it shorter, I still think it's the right trade-off :)
> 
> -- 
> Thierry Carrez (ttx)
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev