Development Process Overview

Welcome to the FreeBMD Development Process Page.

The tools used in the development process are trac (issue tracking system) and CVS and SSH (Control Version System and Secure Shell).

If you intend to do any development work on FreeBMD you will find the following links helpful:
What is CVS?
Guide to Using trac (found in trac itself)
CVS Independent Mode
CVS Co-operative mode

The trac and CVS/SSh utilities are independent of each other, and people requesting changes, and proof-readers who are checking the changes, need only know how to use trac.

Developers who will implement the changes also need to be able to use trac, but in addition will also need to have a working knowledge of CVS and SSh. These are needed to access the files to be edited, and to return them to be tested prior to deployment on the live system. The same approach is taken to changes to the code, to web pages or to data (e.g. district map files).

Sources of Ideas

• Discussions on FreeBMD-Discuss
• Discussions on FreeBMD-Scratchpad
• Ideas mailed in

How the Process works

1. The first step is to create a record of the fact that a change is to be made. This can be done before we have agreed exactly what change is needed.

2. The idea for improvement is recorded in trac as a task by the Requester. Recording the request rather than trying to remember it ensures that we don't lose any ideas. The task is assigned to the pseudo user todo

3. After the task is recorded, each of the development team will receive an email message informing them that a new task has been set in trac.

4. Subsequently, a member of the development team (the Developer) will, depending on his or her area of expertise and level of proficiency, assign the task to him or her self and set the task to 'In progress'.

5. When the Developer has made the requested changes, he or she will upload the file(s) to the development server and test the changes on the FreeBMD test site using CVS.

6. Once the Developer is happy with the changes, he or she will assign the task back to the Requester in trac, as 'Ready for Testing'.

7. The Requester will then receive an e-mail informing him or her that the task is ready for testing. If the Requester is happy that the changes meet with his or her requirements, the Requester will assign it back to the Developer as 'Tested OK'.

8. If the changes are not what the Requester expected, he can assign the task back to the Developer and set the status to 'Re-work needed'. The Developer can then amend the task before handing back to the Requester for testing again.

9. When the task is accepted as 'Tested OK', the Developer will 'tag' each changed module in CVS, and assign it to the pseudo user deploy in trac as 'Ready to Deploy'.

10. The completed task will be transferred to the production server to bring it 'live' and then the task will be closed in trac.

Notes

• When committing a change in CVS the accompanying log message should include the task number involved. Several files may need to be changed and they can all be included in the one commit.
• In general a commit should only relate to one task
• If changes are made in addition to those required by the task (e.g. correcting a spelling error) this should be noted in the log message. Only minor changes may be included in this way.
• When the final change is moved to being owned by "Please deploy" the comment should include the names and revision numbers of the files involved.
• Changes to html pages will require use of the GTML macros - see the GTML documentation

FreeBMD Main Page

Search engine, layout and database Copyright © 1998-2022 Free UK Genealogy CIO, a charity registered in England and Wales, Number 1167484. We make no warranty whatsoever as to the accuracy or completeness of the FreeBMD data. Use of the FreeBMD website is conditional upon acceptance of the Terms and Conditions