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 <rbry...@redhat.com
<mailto:rbry...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev