----- Original Message ----- > On Dec 13, 2017, at 12:13 PM, Tim Bell <tim.b...@cern.ch> wrote: > > > There is a risk that deployment to production is delayed, and therefore > > feedback is delayed and the wait for the ‘initial bug fixes before we > > deploy to prod’ gets longer. > > There is always a rush at the Feature Freeze point in a cycle to get things > in, or they will be delayed for 6 months. With the year-long cycle, now > anything missing Feature Freeze will be delayed by a year. The long cycle > also means that a lot more time will be spent backporting things to the > current release, since people won’t be able to wait a whole year for some > improvements. > > Maybe it’s just the dev in me, but I prefer shorter cycles (CD, anyone?).
And the QE in me says that there are enough moving parts around for the integration testing (because CD yes, but the resources are limited) that a longer cycle with a longer time between freeze and release is better to refine the testing part. The cycle as it is, especially for people working both upstream and downstream at the same time, is complicated enough. If you trust master, as others suggested in this thread, just use master. Let people that wants stable releases use them. -- Luigi __________________________________________________________________________ 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
