Developer Responsibilities

Subscribe to the mailing list

Join the gpstk-announce and the gpstk-devel mailing lists to keep abreast of changes to the GPSTk. You can fine info on GPSTkEmailLists.

Tell others what you are doing

Bugs must be reported and tracked in the Sourceforge bug list. New ideas and enhancements should be explored in the Development web, by raising a BrainstormingIdea. When common understanding and agreement is reached, the work should continue as one item or be broken down into individual tasks that are FeatureUnderConstruction.

Follow the check in process

When considering adding new or modifying existing functionality, the GuidelinesForSubmissions provides important information that guides the process.

Also, you must always "svn update" before you check in, to ensure you are using the head of the branch. All hell will break loose if you fail to do this.

svn update

(this will report the pre-checkin version number of the repository)

Document your changes

This documentation might be in a variety of place considering the change. It might need to go into the Doxygen documentation inline with the code, into the users manual, or into an application specific page.

Test and review at regular intervals

It goes without saying that all changes should be tested before, and preferably after, check-in. As well as that, you should continuously monitor the health of the repository. The easiest way to do this is to use the GPSTk test suite documented at TestingGPSTkBuilds.

If something breaks, fix it

If a change is committed that breaks the code at the head of the branch it is the responsibility of every member of the community to correct the problem. It is never someone else's problem (even if they broke it) it is always your problem.

Revert your changes that are inappropriate

If you submit a change that is subsequently felt by consensus to be inappropriate, or inadequate, or against the GPSTkMission, then you are responsible for removing that change from the repository.

Observe the coding standards

• See CodingStandards

Know how to use your tools

• See the SubversionReadme

Discussion