<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 18, 2013 at 10:20 AM, Jarret Raim <span dir="ltr"><<a href="mailto:jarret.raim@rackspace.com" target="_blank">jarret.raim@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> It is a difficult thing to measure, and I don't think the intent is to set<br>
a hard %<br>
> for contributions. I think the numbers for Barbican were just illustrating<br>
the<br>
> fact that the concrete contributions are very coming very heavily from one<br>
<br>
> source. That's only one data point, though, and as you point out there are<br>
a<br>
> lot of other way to contribute.<br>
<br>
</div>Agreed. I don't think the conclusion (e.g. Barbican is mostly a Rackspace<br>
driven endeavor at the moment) was incorrect, just that if we are going to<br>
codify the social requirement, we need to have a larger definition than just<br>
code commit %.<br>
<div class="im"><br>
> For example, another criteria could be whether the project has core<br>
reviewers<br>
> from multiple companies, where each is doing some significant proportion<br>
of reviews.<br>
<br>
</div>A good option. Still leaves the chicken and the egg problem of how to get<br>
other ATCs interested in reviewing patches for a product they don't work on<br>
that may not be incubated.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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?</div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
 <br>
> I think we've been lucky on that count. I'm not sure how I feel about the<br>
requirement<br>
> for entering incubation, yet, but I do feel strongly that we need to have<br>
diverse contributors<br>
> when a project graduates from incubation.<br>
<br>
</div>I don't know about lucky or not. If the project has been working in the mode<br>
of not requiring it for years and there have been no problems, why would we<br>
assume they would somehow start? Shouldn't we optimize for the data we have<br>
rather than a guess of future pain? On the technical side, most of the<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The question is when to put that "diversity" requirement in place.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

requirements should be driven from things that have caused pain to OpenStack<br>
projects (rather than sacred cows / opinions / guesses of future pain). They<br>
should be discussed, agreed upon and documented before projects get into the<br>
incubation cycle so that everyone knows the goals going in. The social<br>
requirements seem like they should meet the same standard.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Yes, hence this email thread. :-)</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
To me, we just need to codify the risk of a project failing to integrate<br>
after incubation. What would be the downside if we incubate a product that<br>
subsequently needs to be removed (for technical or social reasons)? How much<br>
pain does this cause? Is it worth turning away or slowing projects that<br>
solve needs for OpenStack to avoid this pain?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We already have data that says there is a low chance of this happening, so<br>
how much do we want to optimize to reduce that risk before we just accept<br>
that it is there and deal with it when it happens?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">What data are you citing? We haven't done this very many times.</div><div class="gmail_default" style="font-size:small">
<br></div><div class="gmail_default" style="font-size:small">Doug</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There seems to be broad support for the 'required for graduation' bar, which<br>
I'm fine with. It seems like we just need to nail down whether it is<br>
required pre-incubation or not.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Jarret<br>
<br>
<br>
</font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>