On 13/11/13 13:49 +0100, Thierry Carrez wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Sean Dague wrote:
[...] Proposed Incubation requirements
================================ Once something becomes an
integrated project, it's important that they are able to run in the
gate.

Both devstack and devstack-gate now support hooks, so with a couple
of days of work any project in stackforge could build a gate job
which sets up a devstack of their configuration, including their
code, running some project specific test they feel is appropriate
to ensure they could run in the gate environment.

This would ensure an incubated project works with OpenStack global
requirements, or if it requires something new, that's known very
clearly before incubation.

That makes sense, my only concern with it is, how much support from
QA/Infra would actually be needed *before* incubation can even be
requested. One of the ideas behind the incubation status is to allow
incubated projects to tap into common resources (QA, infra, release
management...) as they cover the necessary ground before being fully
integrated. Your proposal sounds like they would also need some
support even before being incubated.

Incubation requirements should be related to the project maturity,
scope and fit within OpenStack, IMHO. Integration with the whole
OpenStack infrastructure should come later since it also depends on
the acceptance of the project as part of OpenStack incubated projects.

That being said, the integration, where it makes sense, should be a
requirement, i.e use of oslo.config.

I see the incubation process as a way to evaluate if a project fits
under OpenStack's umbrella.


Also does it place a requirement that all projects wanting to request
incubation to be placed in stackforge ? That sounds like a harsh
requirement if we were to reject them.

TBH, I thought it was. If it is not, we should make it clear, unless I
completely missed something.


(sidenote: I'm planning to suggest we create an "emerging technology"
label for projects that are (1) in stackforge, (2) applied for
incubation but got rejected purely for community maturity reasons.
Projects under this label would potentially get some limited space at
summits to gain more visibility. Designate belongs to that category,
but without a clear label it seems to fall in the vast bucket of
openstack-related projects and not gaining more traction. Not sure we
can leverage it to solve the issue here though).

Sounds interesting. Separate thread?


Proposed Graduation requirements ================================
All integrated projects should be in the integrated gate, as this
is the only way we provably know that they can all work together,
at the same level of requirements, in a consistent way.

During incubation landing appropriate tests in Tempest is fair
game. So the expectation would be that once a project is incubated
they would be able to land tests in tempest. Before integrated
we'd need to ensure the project had tests which could take part in
the integrated gate, so as soon as a project is voted integrated,
it has some working integrated gate tests. (Note: there is actually
a symmetric complexity here, to be worked out later).

+1 -- I think we already made that decision for any future graduation.

+1

[...] Raised Questions ================ - what about existing
incubated projects, what would be their time frame to get with this
new program - what about existing integrated projects that
currently don't exist with either an upgrade or gate story? - what
about an upgrade deprecation path (i.e. nova-network => neutron,
nova-baremetal => ironic)

The transition for existing incubated/integrated projects is an
interesting question. I think it's fine to require that
currently-incubated projects get into the integrated gate before they
can graduate.

I think this is important and it *has* to be a strong requirement.

For currently-integrated projects that are not up to
snuff, I think we should strongly suggest that they fix it before the
icehouse release, otherwise the next TC might be driven to make
unpleasant decisions.

+1

Cheers,
FF

--
@flaper87
Flavio Percoco

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to