MS RFC 7:MapServer CVS提交管理

日期

2005/09/22

作者

弗兰克·沃默丹

联系

Pobox.com上的Warmerdam

状态

采用

备注

此RFC被取代 RFC 7.1

目的

规范化cvs提交访问,并为cvs提交者指定一些指导原则。

选择cvs提交访问

只有在MapServer技术指导委员会接受的情况下,才应向新开发人员提供CVS提交访问许可。应向贸易及供应链委员会提交一份新委员的提案,并正常投票。没有必要为这些投票写一个RFC文档…给mapserver dev发电子邮件就足够了。

移除cvs提交访问应该由同一个过程处理。

新的提交者应该表现出对MapServer的承诺以及对MapServer源代码和流程的了解,以使委员会满意,通常通过报告错误、提交补丁和/或积极参与各种MapServer论坛。

新提交者还应准备好支持他/她在未来版本中提交给MapServer源代码树的任何新特性或更改,或者如果他/她停止支持他/她负责的代码部分,则应找到负责这些特性或更改的人。

所有提交者也应该是mapserver dev邮件列表的成员,这样他们就可以随时了解策略、技术开发和发布准备。

提交者跟踪

所有项目提交者的列表将保存在每个CVS提交者的主MapServer目录(称为提交者)列表中:

  • userid:将出现在此人的CVS日志中的ID。

  • 全名:用户的实际名称。

  • 电子邮件地址:可以联系提交者的当前电子邮件地址。它可能会以正常的方式改变,使自动收割更加困难。

  • 职责范围的简要说明。

cvs管理员

技术指导委员会的一名成员将被设计为CVS管理员。该人员将负责向人员授予cvs commit访问权限,更新committers文件,以及其他与cvs相关的管理。当然,此人需要在CVS服务器上进行登录访问。

最初,Steve Lime将担任CVS管理员。

cvs提交实践

以下是MapServer项目的良好CVS提交实践。

  • 对cvs提交日志条目使用有意义的描述。

  • 在提交与Bugzilla中的Bug相关的更改时,在cvs提交日志条目的末尾添加类似“(Bug1232)”的Bug引用。

  • 在历史文件中包含一个条目,用于在主MapServer源树中提交的任何重大更改或错误修复。确保它放在正确的版本标题下,并在这些消息中包含错误号。

  • 如果没有相应的错误ID和历史记录条目,则不应在稳定的分支中提交更改。任何值得推进到稳定版本的变更都值得一个bugzilla bug和良好的历史记录。

  • 永远不要向稳定的分支提交新特性:只有关键的修复。新特性只能放在主开发主干中。

  • 在预发布代码冻结期间,只应对代码提交错误修复。

  • 在进行主要开发版本的重大更改之前,应该在-dev列表中进行讨论,而较大的更改将需要TSC批准的RFC。

  • 未经TSC批准,不得新建分支机构。假定发布管理器具有创建分支的权限。

  • cvs中的所有源代码都应该是unix文本格式,而不是dos文本模式。

  • 在提交新特性或对现有源代码进行重大更改时,提交者应采取合理措施,确保源代码继续在最常用的支持平台(当前为Linux和Windows)上构建和工作,可以直接在这些平台上进行测试,也可以从其他正在工作的开发人员那里获得帮助。在那些平台上。如果添加了新文件或库依赖项,则configure.in、makefile.in、makefile.vc和相关文档应保持最新。