[openstack-dev] [all] Timeframe for future elections & "Release stewards"

Thierry Carrez thierry at openstack.org
Sun Sep 11 15:22:39 UTC 2016


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)



More information about the OpenStack-dev mailing list