CVS问题探讨

watercloud

想了很久好像CVS在这里没有多大用处。
郁闷

不过包的依赖关系图必须先建立起来。

一个可以讨论的方案：
写一个脚本根据依赖关系图自动从CVS上的代码开始编译打包，升级编译
服务器的对应包；然后处理下一个包。
打包前宣布一个日期，大家都必须在这之前把自己负责的包的代码check in。
这个方案没有多大的管理上的进步，只是加了点自动化辅助，不知道有没有用。

cobranail

同意楼上的……

watercloud

[quote:a153b2175d="watercloud"]想了很久好像CVS在这里没有多大用处。
郁闷

不过包的依赖关系图必须先建立起来。

一个可以讨论的方案：
写一个脚本根据依赖关系图自动从CVS上的代码开始编译打包，升级编译
服务器的对应包；然后处理下一个包。
打包前宣布一个日期，大家都必须在这之前把自己负责的包的代码check in。
这个方案没有多大的管理上的进步，只是加了点自动化辅助，不知道有没有用。[/quote]

又想了想应该还是可行的，自动编译和升级系统过程中某个包有问题整个编译打包升级过程停下来也影响不大，修正好这个包后继续即可。

moslinux

我想做一个发行就象建造一个宏伟的大厦一样复杂，但是工作都是一步步来的，在所有的工作之前，一个建筑的蓝图，也就是大厦的详细施工图纸是要先设计出来的，在图纸设计出来后，大家分工协作，就非常容易了。
具体的发行版本的蓝图，我想各个发行内部肯定都有，我们现在可以直接借鉴的“图纸”是LFS.BLFS,上面编译的方法，依赖关系等都非常清晰的描述出来了。我想cjaker有了LFS、BLSF后就可以放弃一些系统的整体架构设计、包依赖关系等琐碎的问题，集中精力来解决国际化、中文支持和使用者的具体使用需求等问题，并能在最快的时间内对LFS、BLFS进行修改，这样其他参与开发的同志就能据以编写spec，最终打包，Magiclinux的发行速度将更快了。
目前国外就有直接以lFS兼容的发行版，这对协作开发在期初团队比较分散，精力不是很集中的情况下应该是一个不错的选择。