Magic Linux操作系统开发管理草案
1. 开发成员协作方式
国内协同开发已经有几个站在做了，如共创联盟和linuxforum。但效果都不是很好。sourceforge的全套系统用齐的没几个。主要原因是速度太慢和步骤过于复杂。web界面协同看来不能够满足要求。因此，Magic Linux的开发将倾向于论坛和mailinglist的结合。论坛用于文档和常见bug的搜集，mailinglist用于补丁和bug的提交。这样补丁和截图的传递可以通过e-mail进行，开发者收取e-mail后马上就可以存盘验证，非常快捷，而且服务器的负荷也可以降到最低。
2. 软件包管理
Magic Linux由于采用网上协作，管理上很难同步。因此采取分包管理的制度。每个小组成员领取相应的源码包，负责维护和更新。
如果每个小组将自己编译后的rpm和src.rpm上传的话，我们就可以保证获得最新的包。但这样也带来一些问题。因为每个人的机器不同，安装的软件包也不一定一样，所以编译的时候相关联的包很难统一。而且从源码包中解出补丁也很繁琐。
为了解决这个问题，软件包管理小组将只上传补丁包和spec文件，采用的系统是cvs，形成一个补丁和spec文件的cvs树。这样做的好处就是可以减少上传和下载的时间，因为交换的只有补丁和spec文件。从cvs更新也十分方便，编译的时候维护人员甚至可以保留原来已经编译好的程序，只编译修改的部分，大大节省了时间。
这种办法的缺点就是不能从根本上解决包之间的依赖关系，也就是说成员还是在自己的机子上编译，很难保证自己机子上的都是最新更新的包，如果一个一个检查的话，将会比较繁琐。
要解决软件包间依赖关系的问题，我们将采取统一编译的方法。也就是说要有统一的编译服务器，里面存放的是经过验证的最新的ML源码，每个软件包更新的时候，测试人员将在统一的服务器上编译测试，确认后将源码安装在服务器上。因为编译时只需要源码的头文件，不需要二进制程序安装，这样可以保证每次编译出的rpm包都是符合最终系统依赖关系的。然后，为了保证不同时间编译的软件包之间的相互关系，我们将定期重新编译所有更新的和相关的rpm包。
下面举个升级qt的例子，说明一下软件包维护的过程。
1. Conner从网站上收到qt打印的补丁，准备进行更新。
2. 下载并解压最新的相应的qt 3.1的官方包。
3. 从Magic Linux的cvs树上下载最新的补丁集和spec文件。
4. 应用以前的补丁。对于可能会影响本次打印补丁的补丁将不予采用。
5. 检查现有补丁是否可以应用到被以前补丁修改过的源码中，如果不能，则修改补丁使之可行。
6. 编译现有代码并安装，看是否可以实现应用补丁所期待的结果。
7. 验证完毕后修改spec文件，加上本次的patch补丁，同时写好修改日志。并同现有的打印patch一起提交到测试人员手中。
8. 测试人员在统一的源码服务器用所提交的spec文件编译qt，生成二进制和源码的rpm包，如果有问题则返回错误信息给Conner检查，如果没有问题，则安装devel头文件，更新服务器。
9. Conner收到测试人员成功编译的确认后将新的打印补丁提交给qt小组审核，附带更新的说明和理由，格式由开发小组统一确定。
10. 到预定更新时间时，编译组将在统一服务的服务器上执行统一编译，生成本次所需更新的rpm二进制和源码包。
11. 更新积累到一定时间，Magic Linux将推出新的版本，总结上个版本后的所有更新。
引用:
注：如果是软件包官方升级，则需检查现有的patch是否仍然有效，然后将仍然有效的patch和新的spec文件上传。
本草案尚待完善，请大家多提建议和意见。等Magic Linux的几台服务器到位后将进入试运行阶段。
公社技术总监兼计划部部长 Conner Mo
