<div dir="ltr">On 24 May 2016 at 02:28, Gregory Haynes <span dir="ltr"><<a href="mailto:greg@greghaynes.net" target="_blank">greg@greghaynes.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>




<div><div><div class="h5"><div>On Mon, May 23, 2016, at 05:24 PM, Morgan Fainberg wrote:<br></div><br><blockquote type="cite"><div dir="ltr"><div><div>I really do not want to "special case" swift. It really doesn't go with the spirit of inclusion.<br></div>
</div><div>
</div>
</div>
</blockquote><div> <br></div>
</div></div><div>I am not sure how inclusion is related to special casing. Inclusion here implies that some group is not being accepted in to our community. The excluded group here would be one writing software not in python, which is the same groups being excluded currently. This is an argument against the status quo, not against special casing.<br></div><span class="">
<div> <br></div></span></div></blockquote><div><br></div><div>It excludes any other project that might be possible under the more relaxed rules. It says 'swift is a special snowflake that the rules don't apply to, but you are not special enough, go away', which is the very definition of exclusionary.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span class=""><div></div>
<blockquote type="cite"><div dir="ltr"><div><div><div>I expect we will see a continued drive for whichever additional languages are supported once it's in place/allowed.<br></div>
</div>
</div>
</div>
</blockquote><div> <br></div>
</span><div>That is the problem. The social and debugging costs of adding another language are a function of how much that other language is used. If one component of one project is written in another language then these costs should be fairly low. I agree that once we allow another language we should expect many projects to begin using it, and IMO most if not all of these cases except swift will not be warranted. </div></div></blockquote><div><br></div><div>So designate have come up with a use-case detailed in this thread. Gnocchi have suggested they might have one. Others quite possibly exist that haven't even been explored yet because the rules were against it. <br><br></div><div>One alternative to ffor swift to split into two layer, a control plane and a data plane, and for alternative dataplane implementations (i.e. the go one, maybe something ceph based, etc) to sit outside of the openstack umbrella. This is the model nearly every other openstack service has.<br></div><div><br><br>-- <br>Duncan Thomas</div></div>
</div></div>