Proposal 2.1 OGDI Source Maintainer Guidelines

Summary

Objectives

1. To ensure that changes to the OGDI core affecting the specification (core client API, and network protocol) are not made without approval of the OGDI Working Group.

2. To ensure the OGDI community received appropriate notification of changes occuring to the source.

3. To ensure the OGDI community has an opportunity to provide comment and input so that the source will be as useful as possible.

4. To ensure the source maintainer has the authorization to make necessary maintenance changes to the core source to keep OGDI progressing, and to popularize it.

General Principles

1. Detailed notes should kept on source changes.

2. Notification of non-trivial maintenance changes should be made to the OGDI developer community.

3. Changes affecting the core C API or the OGDI Network Protocol must be formally proposed to the OGDI Working Group, and approved.

4. The source maintainer should endevour to increase the utility of the OGDI core source code for the sake of easier integration by 3i members, and to encourage the more widespread use of OGDI technology.

Procedures

1. Detailed notes should be kept on source changes.
   • Reasonably detailed information on files changes, and the objectives of changes should be kept in the ChangeLog file in the root of the OGDI source distribution. These entries will be dated, and attributable to a maintainer in the usual manner of ChangeLog files.
   • OGDI source will be maintained under CVS source control.
   • Major public releases of OGDI source code will have a symbolic tag associated with them on all modules in CVS so users can easily use CVS to identify changes to files between releases.
   • Change commits to CVS will be accompanies with a descritive log message, making it easier to identify what changed.
   • Source files will include standard file headers including a keyword so commit messages are visible in the source files. (This will not necessarily be applied to "non-core" source, such as external libraries like rpc, zlib, or contributed code such as drivers).
   • Bugs reported by members of 3i (or even non-members, if the maintainer feels the bug is significant) should be tracked in the SourceForge bug tracking system, and reasonably full explanations of fixes should be placed there.

2. Notification of non-trivial maintenance changes should be made to the OGDI developer community.
   • Email summarizing planned changes should be sent to the public OGDI developers mailing list (ie. ogdidev@egroups.com).
   • The member community should have an opportunity to respond, and discuss the changes on the mailing list before changes are irrevocably applied.
   • In case of objection from a paid 3i member on planned changes, the proposed change should be passed on to the OGDI Working Group for consideration before being irrevocably applied.

3. Changes affecting the core C API or the OGDI Network Protocol must be formally proposed to the OGDI Working Group, and approved.
   • Proposals for changes affecting the core C API, or network protocol should be submitted in written form to the OGDI Working Group at least one week before a meeting intended to address the proposal.
   • The proposals should be made public (via the public OGDI developers mailing list) to give the community an opportunity to provide comment to the working group.
   • Only once approved by the OGDI Working Group should the changes be irrevocably applied to the source tree.

4. The source maintainer should endevour to increase the utility of the OGDI core source code for the sake of easier integration by 3i members, and to encourage the more widespread use of OGDI technology.

   The source maintainer has some freedom to pursue improvements to the OGDI code without prior instruction of the OGDI Working Group if it makes the code easier to utilize. This would include:

   • Changes to make the code easier to build.
   • Porting to different platforms, or build environments.
   • Improving configuration options - for instance, making it possible for some builders to substitute other zlib implementations, or to build in proprietary extensions.
   • Preparing binary releases of libraries and/or tools for various platforms.
   • Preparing automated test suites.
   • Performing testing.
   • Providing some level of unofficial support to users and developers.
   • Low key promotion of OGDI in technical forums (such as newgroups like comp.infosystems.gis, or mailing lists like gistrans).