| ARM由于多方面原因是个有趣的平台 ，CentOS生态系统中的许多人经常谈论应该有一个原生、被持续维护和同步的CentOS ARM版本
。但有些重要的缺失让我们（和其他人）不能实现这个想法。其中最重要的是 CentOS-6夫人
代码现在太老了，以至于现在很多ARM开发的很酷的东西不包括在内（GCC版本、内核版本、glibc等），而且后端大量的代码确实是超出了我们在过去
核心技术领域 的能力范围。同时，这个水平的变更需要分支CentOS代码，重建潜在的孤立包。这个问题在 CentOS-7代码中不存在 ，看一下
RHEL7beta1的 代码就清楚了，它条例清晰，我们应该能够围绕它开启 ARM 的故事。 另一个挑战是发现并且处理合理的硬件，我们也许能够针对ARM的对CentOS进行修改工作。最后，David Power和 Boston UK 的人在 Viridis, ARM as a Service Cloud上提供了很多的例子。 这些是ARM32的难点，他很难在合理的速度构建，测试(Johnny上周使用测试用的 gcc用了8个小时完成了构建)。 我们在此希望做的是用fedora19来替换rhel7beta进行ARM32的构建(fedora19在这些节点上运行的很好)。在之前遇到的情 况,我们要尝试，看看我们是否能得到一个自托管的方法，来迎接的EL7 GA公告。其目的是，试图建设+提供一个与主线x86_64的发行版同步的ARM32发行版。 这将是公平的工作，而且我们也需要更多的人来帮助构建与测试，同时也需要更多的厂商给我们提供的硬件，然后我们可以用它来构建新的版本，进行测试。我们在 http://lists.centos.org/mailman/listinfo/arm-dev 有一份名单，叫做Arm-Dev, 我们将尝试呼吁整个互联网的力量来完成这项工程。 目前的状况是，约翰尼负责压力测试，编写一些测试版本，编写了模拟的configs。一旦做到这一点，我们会完成reimzul的建设，并开始接受进一步建设的要求，建立补丁，并开始推动建立日志等。 挑战之一仍然是那个大红帽商标和品牌追捕到rhel7beta代码并没有发生 - 这是从闭源的i686和x86_64的RPM包中看出来的。我们确实有一个小计划，在四月之前开展第二周社区活动，建设白名单和黑名单，欢迎你们将你们的 RPM或者是一些自动化的补丁加入我们的白名单中。一些规则的细节将在之后公布。 在此同时，欢迎各位参与CentOS-7beta（和持续）的ARM32构建工作。我们希望看到你名字出现在ARM-dev的邮件列表上。 |
