Linux发行版本有很多，其中比较流行的两个社区版本是Fedora和Ubuntu。一般情况下，我们可能只是使用Linux的这些发行版本，但却对他们各自社区的运营模式很少去理解。换言之，我们很少真正地参与到社区的工作中去。在这里我想与大家分享如何参与到Fedora社区的实际工作活动当中。实际上社区里面的工作非常丰富且具有挑战性。理解了社区的运营模式，任何人，只要你有足够的技术能力和热情，都可以为社区的成长贡献一份力量，也许下一个Linux的发行版本中，就会有你贡献的一份实际力量 :-)
首先我们必须理解一个基础知识：Fedora是基于RPM进行发行的。每一个Fedora的发行版本都是由无数的RPM包组成。这些包里面包含了 Linux系统所需的各种软件。如果你是一名程序员，做了一个很不错程序想在Fedora里面进行分发，那么就必须学会打RPM包，并提交到Fedora 社区进行Review。一旦Review通过，你编译的包就将被下一个Fedora发行版本所包含。
可能有的朋友会问，现在不是有YUM了吗？我们通过YUM就可以很方便地安装软件，要RPM还有什么用？其实YUM只是一个壳，它负责管理一个很大的RPM软件仓库。当我们使用YUM来安装软件时，它会帮我们找到相关的RPM包，并负责解决包与包之间的依赖关系。所以，RPM仍然是支撑整个 Fedora的分发的基石。
因此，所谓参与Fedora社区的实际工作，最实际的一个参与方式就是为Fedora提供最新的软件的RPM包。在打包的过程中，我们会遇到各种问题，比如待打包程序中的BUG，编译问题，依赖关系。。。等等，这些所有的活动和相关的人，共同组成了Fedora社区。
好了，现在大概理解了Fedora社区的工作内容，下面我将详细地说明该如何实际参与这些工作。实际上Fedora社区为我们提供了许许多多的工具及资源去进行这些工作，并且这些工作和资源都是开放在互联网之上的。但由于信息量太过庞大，如果没有人指导，很难从这些海量信息中整理出有效的思路该如何参与。这些知识太散乱，连成一条线很困难，但如果按下面我介绍的步骤一步一步来熟悉理解，实际上也相当容易，没什么神秘的，窗户纸一捅就破 :-) 下面我来一一讲解需要掌握的工具：
首先最基础的，需要会生成RPM包，我们平时总是使用RPM安装软件包，却很少去了解这些RPM包是如何生成的，里面都包含有什么内容。实际上每一个RPM包中，都包含着社区成员的辛勤劳动：RPM中包含有已经为我们编译好的软件，并具备了所需的依赖关系，对系统版本的要求等信息。这些东西是由社区成员仔细的工作帮我们完成的，我们在使用RPM或YUM很方便地安装软件包时，须知这个方便的背后包含了多少他人的工作！如果对RPM打包完全不熟悉，建议自己先动手做个RPM试试看。这里有篇详细的教程，需仔细阅读： Maximum RPM
如果你已经学会了RPM打包，那么恭喜你！你已经掌握了最重要的一块内容，剩下的只是Fedora社区的一些工具的使用和相关资源的学习。接下来，你需要申请一个Bugzilla账号。Bugzilla是Redhat非常重要的一个系统，从BUG管理到版本发行都离不开它。很多工作流程是在 Bugzilla里面完成，因此必须在Bugzilla系统中注册一个账号： https://bugzilla.redhat.com/
Bugzilla的账号是开放注册的，只需要一个有效的Email地址即可完成注册。有了Bugzilla账号，我们便可以把自己的RPM包交付Review。Bugzilla里面提供了一个 Review模版 ，供我们把自己的RPM包进行审核。
需要注意的是Review流程是相当严格的，所以在提交之前，最好看看别人是怎么提交自己的RPM包的，书写格式是什么样子，这里有我曾经 提交的一份 ，可供参考。
需要注意的是，提交的RPM包是不允许放在Bugzilla的附件里的，如果提交在附件里会被审核人员删除。需要放在网络上，一个可以公开下载的点，并且必须是Direct Link（点Link直接下载，而不是转到下载页面）。这个可能对于在网上没有私人空间的人是个问题，因此fedora自己提供个人空间，比如 我的 。
但比较郁闷的是，你必须成功地提交过一次RPM并通过Review，才可以拥有fedorapeople的个人空间，又是鸡/蛋问题。所以，你的第一个包只能自己在网上找地方存放，我这里推荐 box.net 还算方便。但它不是Direct Link，但你可以在Bugzilla里面的Description中说明你的问题，并Say Sorry，相信Reviewer不会太过计较 :-)
Ok，现在我们初步学会了如何在Bugzilla提交RPM Review，但还不可以提交！因为，Fedora社区有个要求，你的RPM包必须在Fedora环境中编译成功，才可以提交Review。并且还不可以在自己的Fedora系统上编译，因为那样没有可审计的数据，编译环境也不够标准化。因此，你必须学会如何在koji环境中进行编译。
什么是Koji？Koji是Fedora的编译系统。呃，又出来个新东西，是不是大脑要炸了？哈哈，没关系，本来这篇文章就不是用来在一天内看明白的，很多东西需要慢慢吸收。如果你觉得ok，那么我们继续。做为用户，我们可以把Koji理解成是一个命令+一个WEB端。其中WEB端在 这里 。
在这里，我们可以看到社区成员正在编译以及已经编译成功/失败的包。这些包对应不同的Fedora发行版本，这里面有个名词，叫做target。就是编译的目标。一个target一般情况下对应一个Fedora特定的版本。在koji后面，有大量的编译服务器，这些服务器上面跑着各种各样的 Fedora版本，而我们的RPM包，由Koji负责上传到后面的对应的服务器的相应Fedora版本当中，并由Koji进行RPM打包过程的日志记录。
而我们的包要编译到什么target当中，都是通过调用koji的命令来完成的。因此现在你理解了，koji是一个中央的，可审计的编译系统。要想在Bugzilla里面提交RPM包，必须将你的包在Koji里面成功编译过。有关Koji的使用，可能需要一周甚至几周来学习，但一旦学会，便会发现其实十分简单，这里有篇关于Koji的使用文档，需要仔细阅读 这篇文档 。
为了使用koji，我们必须拥有fedorapeople的账号，关于fedora账号的申请已有详细的文档在 这里 ，请仔细阅读。
申请完账号后，为了能够使用Koji进行编译，我们还需要准备数字证书， 这篇文档 的"Get a Fedora Account"和"Install the Client Tools (Koji)"两段非常详细地说明了Koji的安装方法，请仔细阅读。
现在你应该已经在自己的Linux机器上装好了koji，并会使用它。koji的命令其实不难学，但弄明白要像什么target里面进行编译就比较难。一般情况下，我们可能会希望把rpm包打到fedora下一个发行版本中去。在fedora中，最新的版本的target永远叫做rawhide，比如我要把我做的 forge-parent 的rpm编译到rawhide中，那我就会执行：
koji build --scratch rawhide forge-parent-5-1.src.rpm
注意scratch选项非常重要，它代表着这个编译是试编译，非正式编译。只有通过了Review的包，才可以进行正式编译。编译过程会在koji的web端记录，你会得到一个taskid号，通过这个就可以查看你的编译记录及结果。比如我编译 forge-parent 的记录在 这里 。
有了这个编译成功的记录，我们就可以完成Review的填写了。还是请参考我 提交的一份 ，看看格式对不对，以免被拒。
有关Review中要注意的事项和Fedora的工作流程，请参考 这篇文档 ，对流程没有好的理解，可能会被Reviewer挑出不少毛病改好久 :-)
如果你通过了Review，那么恭喜你！你已经成为了Fedora社区的骨干分子了，是具有主要贡献能力的社区成员。接下来便可以申请你的RPM包入库，入库流程请参考 这篇文档 。 你的RPM包将会包含在下一个版本的Feodra当中。
此时你已经被Sponsor，fedorapeople的空间将对你开放，可供你存放自己的东西。关于fedorapeople的使用方法请参考 这里 。
可以说参与Fedora社区的工作是十分有趣并富有挑战性的，如果你对自己的技术实力有信心并愿意参与开源活动，那么Feodra社区一定适合你 :-) 另外，我现在已经是Fedora的Sponsor，如果你有什么问题，可以通过IRC在 irc.freenode.net 的 #fedora-java 找到我。也欢迎给我 发邮件 。