Open Stack

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.)

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

	-Sean

-- 
Sean Dague
http://dague.net