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提交者指定指导原则。有关在地图服务器中使用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/main/COMMITERS中管理：

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

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

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

  • 职责范围的简要说明。

Git管理员

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

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

Git提交实践

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

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

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

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

  • 绝不可能 将新功能提交给一个稳定的分支；只有关键的修复。新功能只能走在主要开发主体上。这也适用于预发布的稳定分支，一旦它们从Main分支出来。

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

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

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

  • 确保获得新功能 msautotest 添加了测试，在正常和异常情况下都可以使用该功能。

  • 在修复细微的或影响不大的错误时，请添加相关的 msautotest 以确保从长远来看，修复措施仍然有效。

  • 确保提交的代码符合https://github.com/MapServer/MapServer/wiki/CodingStyle地图服务器的编码约定

  • 在提交新功能或对现有源代码进行重大更改时，提交者应采取合理措施，以确保源代码继续构建并在最受支持的平台(当前为Linux和Windows)上工作，方法是直接在这些平台上进行测试，或者向在这些平台上工作的其他开发人员寻求帮助。如果添加了新文件或库依赖项，则 configure.in ， Makefile.in ， Makefile.vc 和相关文件应保持最新。

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

投票历史

TBD