MS RFC 7.2:MapServer Git推送管理

日期

2012/10／04

作者

弗兰克·温默丹、汤姆·克莱迪斯和托马斯·邦福特

联系方式

Pobox.com上可了解有关Warmerdam的更多信息

联系方式

hotmail.com上的tomkralidis

联系方式

gmail.com上的tbonport

最后编辑

2012/10／04

状态

草稿

注解

这个RFC废弃了 MS RFC 7.1:MapServer SVN提交管理 .

目的

规范Git推送访问，并为Git提交者指定指导原则。有关在MapServer中使用Git的更多信息，请访问https://github.com/mapserver/mapserver/wiki/workingwithGit。

选择Git推送访问

只有在MapServer项目指导委员会接受的情况下，才允许新开发人员访问Git Push。一个建议应该写给PSC的新委员，并正常投票。不需要为这些投票编写一个RFC文档；向MapServer Dev发送电子邮件就足够了。

移除Git提交访问权限应该由同一个进程处理。

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

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

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

提交者跟踪

所有项目提交者的列表将以https://github.com/mapserver/mapserver/blob/master/committers格式管理，格式如下：

  • userid：将出现在此人的git提交日志中的ID。

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

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

  • 职责范围的简要说明。

Git管理员

项目指导委员会的一名成员将被指定为Git管理员。该人员将负责授予Git Commit对人员的访问权限，更新 COMMITERS 文件和其他与Git相关的管理。

托马斯·邦福特、史蒂夫·莱姆和丹尼尔·莫里塞特将担任git管理员。

Git提交实践

以下是MapServer项目的良好Git提交实践：

  • 对Git提交日志项使用有意义的描述。提交消息应该遵循git提交约定，即简短的一行摘要，最后是一个空白行和一个提供更多细节的段落。

  • 尽可能添加一个类似于“（1232）”的Github问题引用作为提交消息的一部分。

  • 在中包含一个条目 HISTORY.txt 对于在主分支中实现的任何新特性或向后不兼容的怪癖。确保它放在正确的版本标题下，并相应地包括发行号。对稳定分支机构的承诺 not 包括更新到 HISTORY.txt 而是包含一个足够描述性的提交消息。

  • Never 将新功能提交到稳定的分支；只提交关键的修复。新功能只能进入主开发母版。这也适用于从master分支后的预释放稳定分支。

  • 在进行重大更改之前，请在-dev列表中进行讨论。较大的变更需要由PSC批准的RFC。

  • 确保Git中的所有源代码都是Unix文本格式，而不是DOS文本模式。

  • 确保所有提交不会破坏任何现有的测试（或者如果需要，用预期的结果更新测试套件）。

  • 确保获得新功能 msautotest 添加了测试，在正常和异常条件下运行功能。

  • 当修复细微或非细微影响的bug时，添加相关的 msautotest 以确保解决方案长期有效。

  • 根据https://github.com/mapserver/mapserver/wiki/codingstyle，确保提交的代码符合mapserver的编码约定。

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

  • 考虑到MapServer的持续集成设置，使用Github Pull请求而不是直接提交到分支作为在包含之前测试提议更改的实际方法。

投票历史

TBD