Matt Riedemann wrote: >> [...] >> Here is mine: it would fail to take into account that preparation for a >> development cycle starts a few months /before/ PTG, not a just few weeks >> before. > > Do we really expect the next cycle PTL to be planning for the next cycle > midway through the current cycle? That seems pretty extreme to me, when > we're still crunching to the 3rd milestone and trying to wrap things up > for feature freeze, which will determine a lot of what spills over into > the next cycle.
There is /some/ expectation that by the middle of the cycle you start listening to users and start thinking about what you won't be able to accomplish this cycle and should definitely prioritize for the next. It doesn't impact development yet, since as you said most people are crunching to the 3rd milestone. But you are already past your "priority feature freeze", and you can use the Summit to seed your thinking for the next cycle. I totally agree with you that it's difficult for even a single person to switch focus to the next cycle that early. It is precisely why having one specific person starting to think about the next cycle while almost all the others are still wrapping up things can help. That person would gradually involve more and more people (past feature freeze, past RC1...) so that the next cycle doesn't start from nothing. >> Talking with operators at the recent Ops midcycle, they were pretty >> enthusiastic with the idea of having someone take responsibility for a >> release cycle from day 0 (when you start collecting priorities) through >> the development cycle, to release, up to early stable branch backports >> and communication about the work that has been accomplished. The best >> way to achieve that is to have that person designated in the middle of >> the previous cycle, not just a few weeks before the development branches >> open. > > Are there specific bad acting projects that operators are having a > problem with? Like, are there just terrible transitions happening > somewhere in the community that the rest of us don't know about and it's > impacting release-to-release development of major projects? At the current design summit, operators and users trying to communicate their priorities to some projects are routinely turned down by developers saying that the slate is already full or the priorities are already set. And that's fair -- eight weeks into the development cycle is not the best moment to add priorities, so the timing of that feedback was actively preventing it from happening. That is why we are moving most of the feedback dialog to the "Forum" event at the Summit in the middle of the cycle in the future -- sufficiently before the start of the "development" part of the next release cycle that it's still time to listen. But we need someone there to collect their feedback and start thinking about the next cycle, otherwise you're just pretending to listen. That's why I think it's a good idea to have someone more obviously focused on the next cycle designated by then, to coordinate that feedback. But then, each team is free to ignore that suggestion and handle user feedback differently. -- Thierry Carrez (ttx) __________________________________________________________________________ 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
