On 23/02/15 19:14, Joe Gordon wrote:
Was:
http://lists.openstack.org/pipermail/openstack-dev/2015-February/057578.html
There has been frustration with our current 6 month development cadence.
This is an attempt to explain those frustrations and propose a very
rough outline of a possible alternative.
Currently we follow a 6 month release cadence, with 3 intermediate
milestones (6 weeks apart), as explained here:
https://wiki.openstack.org/wiki/Kilo_Release_Schedule
Current issues
* 3 weeks of feature freeze for all projects at the end of each cycle
(3 out of the 26 feature blocked)
* 3 weeks of release candidates. Once a candidate is cut development
is open for next release. While this is good in theory, not much
work actually starts on next release.
* some projects have non priority feature freezes and at Milestone 2
(so 9 out of 26 weeks restricted in those projects)
* vicious development circle
o vicious circle:
+ big push right to land lots of features right before the release
+ a lot of effort is spent getting the release ready
+ after the release people are a little burnt out and take it
easy until the next summit
+ Blueprints have to be re-discussed and re-approved for the
next cycle
I'm sure there's a good reason for this one that I'm not aware of, but
it certainly sounds a lot like declaring a war of attrition against a
project's own contributors.
If core teams think that a design that they previously approved needs to
change because of other changes _they_ approved in the previous release
cycle or a decision _they_ made during the design summit, the onus
should be on _them_ to actively make the change (even if that's as
simple as proposing a patch deleting *a* previously-approved spec - not
the whole lot en masse). To delete everything by default and force the
contributor to get it reapproved is tantamount to handing them a shovel
and forcing them to shift the goalposts themselves. It's flirting with
the line between poor policy and outright evil.
+ makes it hard to land blueprints early in the cycle casing
the bug rush at the end of the cycle, see step 1
o Makes it hard to plan things across a release
o This actually destabilizes things right as we go into the
stabilization period (We actually have great data on this too)
o Means postponing blueprints that miss a deadline several months
I'm yet to be convinced by the solution offered here, but I do think
this is a fairly accurate description of the problem. I always tell
folks that if you want big features to land in the next release, you
have to start working on them as soon as you can finish up on any
release blockers and well before Summit. Mostly that month feels like
dead time, though.
Sometimes I daydream about what it would be like if we had the design
summit a few weeks _before_ the release instead of after. Usually I snap
out of it when I remember the downsides, like having developers under
pressure to fix bugs at the same time as the design summit, or not
having a shiny new release to trumpet at the conference, or everyone
getting excited about new feature discussions and not working on urgent
bugs when they get back. Still, I keep thinking about it...
cheers,
Zane.
__________________________________________________________________________
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
