Open Stack

On Wed, Dec 18, 2013 at 10:20 AM, Jarret Raim <jarret.raim at rackspace.com>wrote:

> > It is a difficult thing to measure, and I don't think the intent is to
> set
> a hard %
> > for contributions. I think the numbers for Barbican were just
> illustrating
> the
> > fact that the concrete contributions are very coming very heavily from
> one
>
> > source. That's only one data point, though, and as you point out there
> are
> a
> > lot of other way to contribute.
>
> Agreed. I don't think the conclusion (e.g. Barbican is mostly a Rackspace
> driven endeavor at the moment) was incorrect, just that if we are going to
> codify the social requirement, we need to have a larger definition than
> just
> code commit %.
>
> > For example, another criteria could be whether the project has core
> reviewers
> > from multiple companies, where each is doing some significant proportion
> of reviews.
>
> A good option. Still leaves the chicken and the egg problem of how to get
> other ATCs interested in reviewing patches for a product they don't work on
> that may not be incubated.
>

I don't remember having that much trouble when we started ceilometer. What
is the perceived risk of working on a project before it is "accepted" at
some level?



>
>
> > I think we've been lucky on that count. I'm not sure how I feel about the
> requirement
> > for entering incubation, yet, but I do feel strongly that we need to have
> diverse contributors
> > when a project graduates from incubation.
>
> I don't know about lucky or not. If the project has been working in the
> mode
> of not requiring it for years and there have been no problems, why would we
> assume they would somehow start? Shouldn't we optimize for the data we have
> rather than a guess of future pain? On the technical side, most of the
>

We do this sort of risk assessment all the time. For internal projects at
DreamHost (and I'm sure at other companies), we lower the risk by having
more than one developer who understands the code. For OpenStack
requirements, we look for a healthy and active development community
supporting the library. Applying similar criteria to new OpenStack projects
seems perfectly reasonable.

More specifically, I would like to have the commitment to a potential new
OpenStack project spread across more than one company. We've recently had
IBM ask to withdraw a driver from nova because they changed directions
internally. I wouldn't want a change in direction (or profitability, or
whatever) in a single driving company behind a project cause it to fail.

The question is when to put that "diversity" requirement in place.


> requirements should be driven from things that have caused pain to
> OpenStack
> projects (rather than sacred cows / opinions / guesses of future pain).
> They
> should be discussed, agreed upon and documented before projects get into
> the
> incubation cycle so that everyone knows the goals going in. The social
> requirements seem like they should meet the same standard.
>

Yes, hence this email thread. :-)


>
> To me, we just need to codify the risk of a project failing to integrate
> after incubation. What would be the downside if we incubate a product that
> subsequently needs to be removed (for technical or social reasons)? How
> much
> pain does this cause? Is it worth turning away or slowing projects that
> solve needs for OpenStack to avoid this pain?
>

I have more of an issue with a project failing *after* becoming integrated
than during incubation. That's why we have the incubation period to begin
with. For the same reason, I'm leaning towards allowing projects into
incubation without a very diverse team, as long as there is some
recognition that they won't be able to graduate in that state, no matter
the technical situation.



>
> We already have data that says there is a low chance of this happening, so
> how much do we want to optimize to reduce that risk before we just accept
> that it is there and deal with it when it happens?
>

What data are you citing? We haven't done this very many times.

Doug



>
> There seems to be broad support for the 'required for graduation' bar,
> which
> I'm fine with. It seems like we just need to nail down whether it is
> required pre-incubation or not.
>
>
> Jarret
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131218/b7b08d93/attachment.html>