Magic Linux操作系统开发管理草案

conner

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

baif

应该加入对编写文档的要求。现在，有没有文档？上哪可以找到？？

conner

[quote:0348885ef7=""]应该加入对编写文档的要求。现在，有没有文档？上哪可以找到？？[/quote]Magic Linux 1.2将不采用开发文档制度，而是沿袭1.1发布软件为主的模式，原因是因为资源的调配利用程度和成员熟悉开发系统程度的还不够高。1.2的改变主要是引入协同开发，从几个人扩展到十几个人，在开发制度上有了质的变化。

1.2版本将引入用户手册，即分为安装，配置和使用三大部分。手册将依据1.2设计框架和选定的软件包进行编写，并和系统开发同步进行。

1.3版本将引入开发文档制度，使得系统的开发具有可延续性和扩展性。

2.0版本后计划加入Magic Linux自身的架构及软件。在1.3的开发维护的基础上，将进一步实现文档管理的集中化，规范化。

计划中2.0的用户界面设计将会体现Magic Linux特有的创意。针对不同种类的应用，如办公，学习，上网，娱乐等等，我们将提供不同的桌面设置，将Linux的可定制性发挥到极限。

baif

[quote:d4f533b4aa="conner"]Magic Linux 1.2将不采用开发文档制度，而是沿袭1.1发布软件为主的模式，原因是因为资源的调配利用程度和成员熟悉开发系统程度的还不够高。1.2的改变主要是引入协同开发，从几个人扩展到十几个人，在开发制度上有了质的变化。

1.2版本将引入用户手册，即分为安装，配置和使用三大部分。手册将依据1.2设计框架和选定的软件包进行编写，并和系统开发同步进行。

1.3版本将引入开发文档制度，使得系统的开发具有可延续性和扩展性。

2.0版本后计划加入Magic Linux自身的架构及软件。在1.3的开发维护的基础上，将进一步实现文档管理的集中化，规范化。

计划中2.0的用户界面设计将会体现Magic Linux特有的创意。针对不同种类的应用，如办公，学习，上网，娱乐等等，我们将提供不同的桌面设置，将Linux的可定制性发挥到极限。[/quote]

尽早建立完整的文档，特别是开发文档，好处的很多的。像你提到的原因固然应当考虑，但是应当鼓励多写开发文档，即使一时班会难成体系，多少也可以当时开发备忘录了。

Kan

Magic Linux操作系统开发管理草案

1. 开发成员协作方式

国内协同开发已经有几个站在做了，如共创联盟和linuxforum。但效果都不是很好。sourceforge的全套系统用齐的没几个。主要原因是速度太慢和步骤过于复杂。web界面协同看来不能够满足要求。因此，Magic Linux的开发将倾向于论坛和mailinglist的结合。论坛用于文档和常见bug的搜集，mailinglist用于补丁和bug的提交。这样补丁和截图的传递可以通过e-mail进行，开发者收取e-mail后马上就可以存盘验证，非常快捷，而且服务器的负荷也可以降到最低。

关于这个方面，用mailinglist从我们公司的情况看的效果不好，邮件一多管理就会出问题。
我还是建议用，Bugzilla作为bug的管理。
如果有更好的项目管理软件，那就会更好。（为什么不在公社组织人做一个呢？）

hubeichenrui

强烈推荐使用bugzilla,mailllist 在我从事过的软件开发公司中没有一家使用的,更何况这是基于网络的分布式合作.更需要一个完善的bug跟踪系统.

linuxlover

看到这样的内容，真是从心底里高兴！

million

支持，建议如下：

1、用MSN协同，传文件很方便，而且可以组织一些小组会议；

2、不采用CVS，很麻烦，而且慢，而是基本系统可以内部使用CVS，其他按照软件包独立进行；

3、维护小组自行寻找存储地点，写patch/spec/shell等，并且进行内部测试；

4、系统小组组合维护小组的包，进行内部测试；

5、发布测试版。

nichoti

用MSN协同？我用LINUX，不想用MSN.

bamfox

对于本项目的时间管理是怎么进行的?我们比较想知道项目处于何种状态?
这样，对大家容易产生激励作用。

bixuan

[quote:b430c18572="nichoti"]用MSN协同？我用LINUX，不想用MSN.[/quote]
想法，但不现实，很多公司的MSN还是禁的，要不干脆加了个NAT，上传文件都是问题！

Kan

[quote:5a5b330929="bamfox"]对于本项目的时间管理是怎么进行的?我们比较想知道项目处于何种状态?
这样，对大家容易产生激励作用。[/quote]
openoffice新出的ogo也是不错的东西，可以用来做项目管理，好像记得还有一个PHPGroup之类的东西，也能凑合着用。

joyfire

有个PHPGroupware
应该不错

jiangtao9999

我没看明白……
能详细的讲解一下吗？或者给个相关的连接……

我是新手

joyfire

www.phpgroupware.org

这个软件是一个群件系统，功能都是模块化的，也就是说你可以在上面填上自己的功能
基本的功能包括团队论坛，日历，进度，项目责任安排，邮件组等等

还有些很乐的功能，比如跟踪美国的股票，yahoo新闻等等

它的语言也是模块化的，可以装载各种语言，目前正是版里只有繁体中文
但是我在网上看到简体中文的模块文件了