RFC 3:GDAL提交者指南
作者:弗兰克·温特丹
联系方式:warmerdam@pobox.com
状态:通过
目的
规范化SVN(或CVS)提交访问,并为SVN提交者指定一些准则。
选择SVN提交访问
只有在GDAL/OGR项目指导委员会接受的情况下,才应向新开发人员提供SVN提交访问权限。应向PSC提交一份新提交人的提案,并正常投票。不必为这些投票编写RFC文件,向gdal dev提交提案就足够了。
删除SVN提交访问应该由同一进程处理。
新提交者应该向委员会展示对GDAL/OGR的承诺和对GDAL/OGR源代码和过程的了解,通常是通过报告错误、提交补丁和/或积极参与GDAL/OGR邮件列表。
新提交者还应该准备好支持他/她在将来的版本中提交给GDAL/OGR源代码树的任何新特性或更改,或者如果他/她不再支持他/她负责的代码部分,那么他/她应该找到一个人来为这些特性或更改委派责任。
所有提交者也应该是gdal dev邮件列表的成员,这样他们就可以随时了解策略、技术开发和发布准备。
新提交者有责任阅读并理解本文档。
提交者跟踪
所有项目提交者的列表将保存在每个SVN提交者的主gdal目录(称为提交者)中:
userid:将出现在此人的SVN日志中的ID。
全名:用户的实际名称。
电子邮件地址:可以联系提交者的当前电子邮件地址。它可能会以正常的方式改变,使自动收割更加困难。
职责范围的简要说明。
SVN管理员
项目指导委员会的一名成员将被设计为SVN管理员。该人员将负责授予SVN提交权限,更新提交者文件,以及其他与SVN相关的管理。当然,此人需要在SVN服务器上进行登录访问。
最初,Frank wartemdam将担任SVN管理员。
SVN提交实践
以下是GDAL/OGR项目的良好SVN提交实践。
对SVN提交日志项使用有意义的描述。
在Trac中提交与票证相关的更改时,在SVN提交日志条目的末尾添加一个bug引用,如“(#1232)”。“#”字符使Trac能够创建从变更集到所述票证的超链接。
在Trac中提交与票证相关的更改后,在票证描述中写入修复该更改的树和修订。例如“固定在主干(r12345)和分支/1.7(r12346)”。“r”字符使Trac能够创建从票据到变更集的超链接。
如果没有相应的bug id,则不应在稳定分支中提交更改。任何值得推入稳定版本的更改都值得进行bug条目。
未经PSC或发布管理器许可,切勿向稳定分支提交新特性。通常只有修复程序才能进入稳定的分支。
新功能进入了主开发主干。
在预发布代码冻结期间,未经PSC或发布管理器许可,只应将错误修复提交给代码。
在进行主要开发版本的重大更改之前,应该在gdal dev列表中进行讨论,更大的更改将需要PSC批准的RFC。
未经PSC批准,不得新建分支机构。假定发布管理器具有创建分支的权限。
SVN中的所有源代码都应该是UNIX文本格式,而不是DOS文本模式。
当提交新特性或对现有源代码进行重大更改时,提交者应采取合理措施,确保源代码继续在最常用的支持平台(当前为Linux和Windows)上构建和工作,或者直接在这些平台上测试,或者运行 [wiki:Buildbot] 测试,或者从其他在这些平台上工作的开发人员那里获得帮助。如果添加了新文件或库依赖项,则configure.in、Makefile.in、Makefile.vc和相关文档应保持最新。
与GDAL/OGR代码库中导入的其他上游项目的关系
GDAL/OGR代码库的某些部分定期从其他上游项目刷新。因此,这些领域的变化应该首先进入那些上游项目,否则它们可能会在以后的更新过程中丢失。注意,这些目录可能包含GDAL特定文件和上游文件的混合。这必须逐个检查(任何开头带有CVS changelog的文件都很适合属于上游项目)
目前,这些领域的清单是:
frmts/gtiff/libtiff:来自libtiff CVS (http://www.remotesensing.org/libtiff/ ()
frmts/gtiff/libgeotiff:来自libgeotiff SVN (http://trac.osgeo.org/geotiff/ ()
frmts/jpeg/libjpeg:来自libjpeg项目 (http://sourceforge.net/projects/libjpeg/ ()
frmts/png/libpng:来自libpng项目 (http://www.libpng.org/pub/png/libpng.html ()
frmts/gif/giflib:来自giflib项目 (http://sourceforge.net/projects/giflib ()
frmts/zlib:来自zlib项目 (http://www.zlib.net/ ()
ogr/ogrsf_frmts/mitab:来自mitab CVS (http://mitab.maptools.org/ ()
ogr/ogrsf_frmts/avc:来自AVCE00 CVS (http://avce00.maptools.org/ ()
ogr/ogrsf_frmts/shape/ [dbfopen.c、shpopen.c、shptree.c、shapefil.h] :来自shapelib项目 (http://shapelib.maptools.org/ ()
data/:一些与CRS相关的.csv文件来自libgeotiff
法律
提交者是前线的看门人,以保持代码库远离不正确贡献的代码。对于GDAL/OGR用户、开发人员和OSGEO基金会来说,重要的是避免在项目许可下明确地授予项目的任何代码。
Generally speaking the key issues are that those providing code to be included in the repository understand that the code will be released under the MIT license, and that the person providing the code has the right to contribute the code. For the committer themselves understanding about the license is hopefully clear. For other contributors, the committer should verify the understanding unless the committer is very comfortable that the contributor understands the license (for instance frequent contributors).
If the contribution was developed on behalf of an employer (on work time, as part of a work project, etc) then it is important that an appropriate representative of the employer understand that the code will be contributed under the MIT license. The arrangement should be cleared with an authorized supervisor/manager, etc.
代码应该由贡献者开发,或者代码应该来自可以正确贡献的源代码,例如来自公共域,或者来自兼容许可证下的开源项目。
所有异常情况都需要讨论和/或记录。
提交者应遵守以下准则,并可能对向源存储库不适当地提供代码承担个人法律责任:
确保出资人(可能是雇主)了解出资条款。
来自贡献者以外的源代码(如改编自另一个项目的代码)应清楚地标明原始源、版权所有者、许可条款等。此信息可以在文件头中,但如果与正常项目授权(gdal/LICENSE.txt)不完全匹配,则也应添加到项目授权文件中。
现有的版权标题和许可证文本不应从文件中删除。如果版权持有者希望放弃版权,他们必须在版权信息被删除之前以书面形式向基金会提交。如果许可条款发生变更,则必须由版权所有人同意(以电子邮件形式书写即可)。
带有需要信任或向用户公开的许可证的代码应添加到/trunk/gdal/LICENSE.TXT中。
当向文件添加大量贡献(如大量补丁)时,应将作者/贡献者添加到文件的版权所有者列表中。
如果不确定是否对代码库有所贡献,请从项目指导委员会或基金会法律顾问处寻求更多信息。
自举
以下现有的提交者将被视为授权的GDAL/OGR提交者,只要他们各自审查提交者指南,并同意遵守它们。SVN管理员将负责与每个人进行核对。
丹尼尔·莫里塞特
弗兰克·沃默丹
吉莉安·沃尔特
安德烈·基塞列夫
亚历山德罗·阿米奇
高德宗
霍华德巴特勒
王立春
诺曼藤
肯·梅列罗
凯文·鲁兰
马雷克布鲁德卡
皮尔明卡贝勒
史蒂夫·苏尔
弗兰斯范德伯格
丹尼斯·纳多
奥列格塞米金
朱利安·塞缪尔·拉克鲁瓦
丹尼尔·沃纳
查尔斯·萨维奇
马修斯洛斯科特
彼得·纳吉
西蒙·珀金斯
布拉泽克
史蒂夫·哈拉斯兹
纳乔·布罗丁
本杰明柯林斯
伊凡·卢塞纳
阿里乔玛
塔玛斯塞克勒斯