Overview

Setup, procedures and guidelines for using Google Code Issue Tracker for My Films Development

Guidelines

Change logs

One of the goals of the Issue Tracker is to generate a list of changes per release. The best way is a report of issues by milestone, even sorted by 'type (feature/defect, etc), since there may be MANY commits per issue and commits/changes are only sorted chronologically Google Code Commits/changes are not useful as change logs..

Commits

1. Every commit should be linked, ideally to one issue per commit (so it can be easily reverted if necessary)
2. If no issue exists, then one should be added 
3. Documentation of a fix that describes the change or how to use a  new feature should be added to the issue (to enable change logs by feature.

New Features

New features should be added to Issue tracker as type 'New', and only changed to 'Accepted' once discussed and priorities set so that milestone can be set accordingly.

Major features which require changes to several existing features or additional of several sub features, should be 'linked' to separate issues for each sub feature. Unfortunately Google Code does not provide a good way to 'group' features. 

Examples: In 6.0.0 'Views Menu'  or 'search,sort,update by any field', should have had several feature issues so they could be tested, verified and documented when complete. It is very easy to miss things when so much is developed in one issue.

Feature Branches

Major new features should be developed in a branch, so that bug fixes can continue for maintenance releases.  We may be able to manage with ONE feature branch for all new feature development. Example:

1. Create a Feature branch (e.g. 6.1) - all new feature development for 6.1 is committed to that branch
2. If additional features are developed for future versions, then additional branches must be created for each version
3. Add bug fixes to trunk for maintenance releases (e.g. v 6.0.x)
4. Merge all bug fixes to all Feature branch(es) (6.1) - hopefully only one
5. Once a Feature Branch is complete and ready for release it can be merged to Trunk and the existing feature branch tagged as release (e.g. 6.1)

Thus release versions are based on Trunk, test versions are built and released from Feature Branch.

However, this does not take into test mode into consideration!

Testing

1. Add a new 'Status' = 'Ready for Testing' - since commits often mark issues 'fixed' it is not clear when they are ready to be tested/verified.  
2. A new feature or rework issue can only be marked 'Ready for Testing' if procedures are documented either in the issue or in Wiki for how to test the feature.
3. If skin properties are added or changed they must be documented in the issue and Default skin files provided with the changes before the issue is marked 'ready for testing'

QA

Ideally every issue should be 'verified' before a final release.

It is currently not easy to fully verify issues since they often contain many features/diff use cases, so a tester may only be able to test some of the use cases.

We definitely need a better process for QA/testing. Even releasing a beta does not ensure all the features have been tested - although we can assume if no issues are reported then the feature either works or is not used!

Related

• Development