Open Stack

On 09/11/2014 07:32 AM, Eoghan Glynn wrote:
>
>> As you all know, there has recently been several very active discussions
>> around how to improve assorted aspects of our development process. One idea
>> that was brought up is to come up with a list of cycle goals/project
>> priorities for Kilo [0].
>>
>> To that end, I would like to propose an exercise as discussed in the TC
>> meeting yesterday [1]:
>> Have anyone interested (especially TC members) come up with a list of what
>> they think the project wide Kilo cycle goals should be and post them on this
>> thread ...
> Here's my list of high-level cycle goals, for consideration ...
>
>
> 1. Address our usability debts
>
> With some justification, we've been saddled with the perception
> of not caring enough about the plight of users and operators. The
> frustrating thing is that much of this is very fixable, *if* we take
> time out from the headlong rush to add features. Achievable things
> like documentation completeness, API consistency, CLI intuitiveness,
> logging standardization, would all go a long way here.
>
> These things are of course all not beyond the wit of man, but we
> need to take the time out to actually do them. This may involve
> a milestone, or even longer, where we accept that the rate of
> feature addition will be deliberately slowed down.
>
>
> 2. Address the drags on our development velocity
>
> Despite the Trojan efforts of the QA team, the periodic brownouts
> in the gate are having a serious impact on our velocity. Over the
> past few cycles, we've seen the turnaround time for patch check/
> verification spike up unacceptably long multiple times, mostly
> around the milestones.
>
> Whatever we can do to smoothen out these spikes, whether it be
> moving much of the Tempest coverage into the project trees, or
> switching focus onto post-merge verification as suggested by
> Sean on this thread, or even considering some more left-field
> approaches such as staggered milestones, we need to grasp this
> nettle as a matter of urgency.
>
> Further back in the pipeline, the effort required to actually get
> something shepherded through review is steadily growing. To the
> point that we need to consider some radical approaches that
> retain the best of our self-organizing model, while setting more
> reasonable & reliable expectations for patch authors, and making
> it more likely that narrow domain expertise is available to review
> their contributions in timely way. For the larger projects, this
> is likely to mean something different (along the lines of splits
> or sub-domains) than it does for the smaller projects.
>
>
> 3. Address the long-running "what's in and what's out" questions
>
> The way some of the discussions about integration and incubation
> played out this cycle have made me sad. Not all of these discussions
> have been fully supported by the facts on the ground IMO. And not
> all of the issues that have been held up as justifications for
> whatever course of exclusion or inclusion would IMO actually be
> solved in that way.
>
> I think we need to move the discussion around a new concept of
> layering, or redefining what it means to be "in the tent", to a
> more constructive and collaborative place than heretofore.
>
>
> 4. Address the fuzziness in cross-service interactions
>
> In a semi-organic way, we've gone and built ourselves a big ol'
> service-oriented architecture. But without necessarily always
> following the strong contracts, loose coupling, discoverability,
> and autonomy that a SOA approach implies.
>
> We need to take the time to go back and pay down some of the debt
> that has accreted over multiple cycles around these these
> cross-service interactions. The most pressing of these would
> include finally biting the bullet on the oft-proposed but never
> delivered-upon notion of stabilizing notifications behind a
> well-defined contract. Also, the more recently advocated notions
> of moving away from coarse-grained versioning of the inter-service
> APIs, and supporting better introspection and discovery of
> capabilities.
+1
IMO, almost all of the other ills discussed recently derive from this 
single failure.

  -David
>> by end of day Wednesday, September 10th.
> Oh, yeah, and impose fewer arbitrary deadlines ;)
>
> Cheers,
> Eoghan
>
>> After which time we can
>> begin discussing the results.
>> The goal of this exercise is to help us see if our individual world views
>> align with the greater community, and to get the ball rolling on a larger
>> discussion of where as a project we should be focusing more time.
>>
>>
>> best,
>> Joe Gordon
>>
>> [0]
>> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
>> [1]
>> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev