MS RFC 7:MapServer CVS提交管理

日期

2005／09／22

作者

Frank Warmerdam

联系方式

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和相关文档应保持最新。