【.com速译】OpenStack一直都是用Python写的。其他语言不是没用只是很少用。核心部分几乎都是Python。有人建议Go语言也可以用在API服务上。方面。在新版Newton的发布周期中，技术评估委员会收到了使用Go语言作为OpenStack官方开发语言的提案。后面有很多讨论，这里就不重复这个过程了，只讲一些讨论的结果。该决议是暂时拒绝Go作为官方开发语言，但表示可以在未来进行讨论。我认为Go被否决可能有以下几个原因：1.技术委员会成员担心增加新语言对社区的影响。会不会给社区带来分裂，会不会形成孤岛，会不会给新人带来额外的进入壁垒？2.技术委员会的一些成员认为当今社区在某些方面缺乏信息、研究和工作。Go代码如何在社区中共享？如何进行认证？消息层呢？如何制作版本？如何维护分支机构的稳定？3.提出Go语言的团队从来没有做过自己项目以外的跨项目任务，这不禁让人产生质疑，让很多技术委员会质疑它能否顺利完成。接受一门新语言的条件是什么？先声明一下，我所说的不代表技术委员会，仅代表个人意见，方便交流，让整个社区的人发表意见，不管是赞同还是反对我的想法。讨论中我最关心的是***部分，主要是因为我觉得向“大帐篷”的迁移还没有完成。我不知道是什么让我觉得这次迁移已经完成，我确信在发生重大变化之前我们需要解决一些问题。事不宜迟，我已经开始喜欢为很多事情设定期望，尤其是能产生影响的要求。列出期望可以让相关人员了解他们正朝着哪个方向前进，并确定变革可能带来的问题。与第一个问题相比，我对第二个问题的担心要少得多。它将显示对参与讨论此更改的团队的坚定承诺，因为它涉及供社区所有成员将来使用和参考的基础知识库。我认为工作的第二部分可能有点过头了，但事实并非如此。通过学习如何分享代码，如何测试代码，如何输出代码，如何制作认证库等，为我们在以后的实际工作中需要用到的东西打下基础。无论如何，我上面提到的“基本东西”是什么？我将在下面的非详尽列表中讨论这一点：定义一种为新语言共享代码和库的方法Oslo团队维护整个OpenStack社区经常使用的库。这些库包括消息库（oslo.messaging）、国际化库（oslo.i18n）、数据库层库（oslo.db）等关键库。这些库不会让Oslo小组自己忙个不停，它们的目的是收集社区中许多项目中曾经存在的重复通用代码。此代码现已由Oslo删除、稳定和发布。我觉得作为一个社区这是不可避免的。越来越多的项目使用相同的语言，因此需要共享代码。因此，我认为我们需要更好地定义编程语言的代码在社区中的共享方式。这非常重要，甚至在编程语言被接受之前。我认为提前做某事并不意味着以后就没有事可做了。我们都知道会有很多意想不到的事情和会发生变化的事情。我认为这些任务可以涉及大部分初始工作。基本OpenStack服务的基本库这似乎是一个非常崇高的目标。虽然弄清楚代码如何共享是一个非常困难的需求，但我认为这远不是OpenStack服务的最佳需求。生态系统中集成的OpenStack服务至少需要以下库之一：?keystoneauth/keystone-client?oslo.config?oslo.db?oslo.messaging如果在使用数据库或消息队列抽象库时没有消耗，则为easy可能会提供错误的抽象层，从而导致糟糕的API。另一方面，认证层是几乎所有OpenStack服务都会用到的部分，使用起来应该会很方便，但这并不代表这件事本身很简单。通过使用这些库中的任何一个，可以执行CI（自动测试系统）作业，从而确保新项目的基本设置是正确的。定义可交付成果的分发方式OpenStack发布过程几乎是完全自动化的，发布过程中涉及的所有可交付成果均由社区自动生成并由发布团队管理。***，为每个交付物生成一个压缩包。当使用Python编程语言（以及其他几种编程语言）时，这些压缩包非常简单，因为它们只包含这些源代码。对于Go这样的编译型语言，我们要考虑压缩包里压缩什么，压缩编译后的二进制代码？是否应该添加源代码？如果你想包含二进制代码，你是否也应该考虑两个不同的档案？一种是二进制代码，一种是源代码。维护稳定分支部分的工作如何？稳定的分支在社区中经常被遗忘，维护这些稳定分支的团队也很少受到赞赏。虽然稳定的分支代码在许多OpenStack云环境中运行，但它们对于向后兼容的后端迁移修复至关重要。每种语言都有自己的分发库和管理兼容性的方式。在向社区添加新的编程语言时，与其他现有团队的协作至关重要。为新语言设置CI流水线，并与基础设施组讨论如何设置CI（自动化测试系统）流水线。这项任务可能是许多工作的基础。为了解决之前的许多任务，有必要建立一个CI（自动化测试系统）工作，这涉及与基础设施团队的协调。后者至关重要。基础架构团队的参与对于添加任何新语言都至关重要，他们的反馈将在许多决策中发挥重要作用。回顾一下为Python语言所做的一些基础工作，其实是大部分项目都需要做的事情。我希望致力于添加新语言的团队可以做一些通用的事情，并在未来跨多个项目使用它。例如，将在以下方面进行一般性工作：?Lint检查器?Doc构建器?ReleasePipelines看起来还有很多事情要做。确实需要花费大量的人力和时间来完成上述所有方面。不幸的是，许多参与的团队真的没有时间做其他事情，所以我认为大部分工作将由各个组中对多种语言感兴趣的人贡献。无论如何，这些努力势必会拖延每个团队的工作，尽管大部分研究、文档和补丁都是由感兴趣的团队自愿完成的。整个社区花费了数年时间使Python达到当前状态。我不希望一个团队工作一周来向已有6年历史的Python系统添加新的语言代码。但是，机制已经建立，团队已经存在，通过共同努力，上述问题可能会在合理的时间点得到解决。我希望这是一个循序渐进的过程，这也是为什么我强调要经过上面的步骤。人是流动的，有时候即使做出承诺也行不通。我认为最重要的是先去做，然后逐渐接受语言。***尽管添加新语言的过程格式正确，但我仍然建议优先使用Python而不是其他语言。这与语言偏好无关，它只是关于我们社区中现有知识的传播，我相信这些知识是无价的，将这些知识转化为一种新语言需要数年时间，而不是优化是一项更容易的任务创新对许多人来说很重要项目。我们也相信不可能永远保持不变，语言会变，项目会上升，项目会消亡等等。添加新语言是社区变化的一部分，我希望OpenStack社区以最好的方式拥抱变化.但我希望以一种相对保守的方式。相信本文提到的任务将帮助您在未来以更快、更安全的方式添加新语言。当然，以上是我个人的看法，越来越执着于明确的期待。因此，我将起草一份正式文件并提交给技术委员会。【翻译稿件，合作网站转载请注明原译者和出处.com】
