Open Stack

>
> Perhaps we should start putting each project on the TC agenda for a
> review of its current standing.  For any gaps, I think we should set a
> specific timeframe for when we expect these gaps to be filled.


Really good idea. New requirements are great, but frankly speaking not all
currently integrated projects fit all of them.
Will be nice to find out all gaps there and fix them asap.

Dina


On Thu, Feb 6, 2014 at 2:47 AM, Monty Taylor <mordred at inaugust.com> wrote:

> On 02/05/2014 10:38 PM, Sean Dague wrote:
>
>> On 02/06/2014 06:31 AM, Russell Bryant wrote:
>>
>>> On 02/05/2014 02:31 PM, Doug Hellmann wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Feb 5, 2014 at 1:24 PM, Russell Bryant <rbryant at redhat.com
>>>> <mailto:rbryant at redhat.com>> wrote:
>>>>
>>>>      Greetings,
>>>>
>>>>      In the TC we have been going through a process to better define our
>>>>      requirements for incubation and graduation to being an integrated
>>>>      project.  The current version can be found in the governance repo:
>>>>
>>>>      http://git.openstack.org/cgit/openstack/governance/tree/
>>>> reference/incubation-integration-requirements
>>>>
>>>>      Is it time that we do an analysis of the existing integrated
>>>> projects
>>>>      against the requirements we have set?  If not now, when?
>>>>
>>>>      Perhaps we should start putting each project on the TC agenda for a
>>>>      review of its current standing.  For any gaps, I think we should
>>>> set a
>>>>      specific timeframe for when we expect these gaps to be filled.
>>>>
>>>>      Thoughts?
>>>>
>>>>
>>>> I like the idea of starting this soon, so projects can prioritize the
>>>> work during the next cycle and have time to plan to discuss any related
>>>> issues at the summit. Setting a deadline for finishing may depend on the
>>>> nature and size of the gaps, but it seems fair to set a deadline for
>>>> *starting* the work.
>>>>
>>>
>>> Well, I think in all cases the work should start ASAP.
>>>
>>> We could set the deadline for when we expect it to be finished on a case
>>> by case basis, though.
>>>
>>
>> First, +1 on doing these kinds of reviews. I think as we've been
>> applying the rules to new projects, we need to validate that they are
>> sane by applying them to existing projects.
>>
>> My feeling is that we've been evolving these new requirements during
>> Icehouse, and it's fair to say that all existing integrated projects
>> need to be up to snuff by Juno, otherwise we take a project back to
>> incubating status.
>>
>> I think it will be really good to do some gap analysis here and figure
>> out where we think we have holes in our existing integrated projects.
>> Because realistically I think we're going to find a number of projects
>> that don't meet are current bar, and we'll need to come up with a way to
>> get them in sync.
>>
>>  From a gating perspective, I think a bunch of our issues are based on
>> the fact that as the number of moving parts in OpenStack expands, our
>> tolerance for any particular part not being up to par has to decrease,
>> because the number of ways a badly integrated component can impact the
>> OpenStack whole is really large.
>>
>
> +100
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140206/449f02d8/attachment.html>