Open Stack

Excerpts from Sean Dague's message of 2016-08-16 10:35:11 -0400:
> On 08/16/2016 05:36 AM, Thierry Carrez wrote:
> > John Dickinson wrote:
> >>>> Excerpts from John Dickinson's message of 2016-08-12 16:04:42 -0700:
> >>>>> [...]
> >>>>> The proposed plan has a lot of good in it, and I'm really happy to see the TC
> >>>>> working to bring common goals and vision to the entirety of the OpenStack
> >>>>> community. Drop the "project teams are expected to prioritize these goals above
> >>>>> all other work", and my concerns evaporate. I'd be happy to agree to that proposal.
> >>>>
> >>>> Saying that the community has goals but that no one is expected to
> >>>> act to bring them about would be a meaningless waste of time and
> >>>> energy.
> >>>
> >>> I think we can find wording that doesn't use the word "priority" (which
> >>> is, I think, what John objects to the most) while still conveying that
> >>> project teams are expected to act to bring them about (once they said
> >>> they agreed with the goal).
> >>>
> >>> How about "project teams are expected to do everything they can to
> >>> complete those goals within the boundaries of the target development
> >>> cycle" ? Would that sound better ?
> >>
> >> Any chance you'd go for something like "project teams are expected to
> >> make progress on these goals and report that progress to the TC every
> >> cycle"?
> > 
> > The issue with this variant is that it removes the direct link between
> > the goal and the development cycle. One of the goals of these goals
> > (arh) is that we should be able to collectively complete them in a given
> > timeframe, so that there is focus at the same time and we have a good
> > story to show at the end. Those goals are smallish development cycle
> > goals. They are specifically chosen to be complete-able within a cycle
> > and with a clear definition of "done". It's what differentiates them
> > from more traditional cross-project specs or strategic initiatives which
> > can be more long-term (and on which "reporting progress to the TC every
> > cycle" could be an option).
> 
> So, I think that's ok. But it's going to cause a least common
> denominator of doable. For instance, python 3.5 is probably not doable
> in Nova in a cycle. And the biggest issue is really not python 3.5 per
> say, but our backlog of mox based unit tests (over a thousand), which
> we've experienced are unreliable in odd ways on python3. They also tend
> to be the oldest unit tests (we stopped letting people add new ones 2
> years ago), in areas of the code that have a lower rate of change, and
> folks are less familiar with (like the xenserver driver which is used by
> very few folks).
> 
> So, those are getting tackled, but there is a lot there, and it will
> take a while. (Note: this is one of the reasons I suggested the next
> step with python3 be full stack testing, because I think we could
> actually get Nova working there well in advance of the unit tests
> ported, for the above issue. That however requires someone to take on
> the work for full stack python3 setup and maintenance.)
> 

Yeah, I don't think we should time-box all goals to one release cycle.
Community goals should be real things that the community needs.

But we can still set a time frame for a goal, like "O+1", and even try
to set objectives that are single-release cycle doable. Like for Ocata
we can say "All dependencies are python3.5 compatible and 80% of tests
pass on python3.5". Then "Integrated gate passes using pyton3.5 in O+1".
Then at the end of each release cycle, we can look at the objectives
completed, and consider whether or not the goal is reached, or what we
can do to make sure it is.

> Maybe this process also can expose "we're going to need help to get
> there" for some of these goals.

Just like with the architecture working group I've been proposing,
I think we need to rally resources around supporting these objectives,
otherwise the TC will just sow frustration.