Open Stack

On Mon, Feb 25, 2019 at 3:13 PM Doug Hellmann <doug at doughellmann.com> wrote:

> Doug Hellmann <doug at doughellmann.com> writes:
>
> > One of the key responsibilities of the Technical Committee is still
> > evaluating projects and teams that want to become official OpenStack
> > projects. The Foundation Open Infrastructure Project approval process
> > has recently produced a different set of criteria for the Board to use
> > for approving projects [1] than the TC uses for approving teams [2].
> >
> > What parts, if any, of the OIP approval criteria do you think should
> > apply to OpenStack teams?
> >
> > What other changes, if any, would you propose to the official team
> > approval process or criteria? Are we asking the right questions and
> > setting the minimum requirements high enough? Are there any criteria
> > that are too hard to meet?
> >
> > How would you apply those rule changes to existing teams?
> >
> > [1]
> http://lists.openstack.org/pipermail/foundation/2019-February/002708.html
> > [2]
> https://governance.openstack.org/tc/reference/new-projects-requirements.html
> > --
> > Doug
>
> One of the criteria that caught my eye as especially interesting was
> that a project must complete at least one release before being
> accepted. We've debated that rule in the past, and always come down on
> the side encouraging new projects by accepting them early. I wonder if
> it's time to reconsider that, and perhaps to start thinking hard about
> projects that don't release after they are approved.
>
> Thoughts?
>
>
My personal opinion on that is that releasing a 1.0 version is just
procedural. Or, said differently, political. It's just a signal saying "we
think we are ready for production".
The problem with that is that it's subjective. No real key metrics to
attribute the meaning of "production-ready" (I'm even not talking of
production-grade), just a feeling that the contributors team ideally, or
just the "PTL" (given the project isn't official yet), considers it ready.
As a consequence, there can be a big gap in between the contributors's
expectations and the reality. That's what I called it "the reality wall".
When you hit it, it's a pain.

I'm more in favor of objective metrics to define the health of a project in
order to be production ready : does this project allow upgrades ? is this
project distributed enough to grow atomically ? can we easily provide
bugfixes thanks to a stable policy ?

Hope that clarifies your concern,
-Sylvain

-- 
> Doug
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190225/5e59c761/attachment.html>