4.1.1 Development Conventions

Technical Committee

Oscar Code design and architecture is overseen by a technical committee.  This is a high level developer group whose responsibilities include further codifying Oscar's development conventions to make it easier for high quality code to predictably be delivered on an ongoing schedule.  What actually gets coded is intentionally free and open.

The idea is to provide tools to make it easier to leverage the code base and interface with group(s) that have an urgent need for a quick feature, while maintaining ISO standards and stability of the core, and of course open-source nature of the project. 

Representation on this committee reflects the diverse backgrounds that Oscar developers have including McMaster, CAISI and independent developers, however if you have code committing privileges and feel that Oscar would benefit from your involvement on this working group please apply to Dr Chan.

Reporting includes the devel list serv and this, the Developers section of the new oscarmanual site.

Versioning Convention

Currently Oscar uses Ubuntu style versioning such that the first part of the version reflects the year of the release and the second part reflects the month.  eg 10.12 refers to Oscar released at the (end) of December, 2010.

Development Cycle

Feature List

Whatever gets funding is placed on the feature development list. 

Items from the wishlist (Recent notable examples of Rx3 and the Inbox) get occasionally incorporated into the code even without funding, on an irregular schedule.

Testing

Like other programs there is a sequence of testing that occurs.  White box testing is done as the programmer codes to ensure that possible inputs are exercised through the code to determine the appropriate outputs.  The CVS itself is monitored by automated half hourly builds.   Black Box or Feature testing as well as Alpha testing is done by clinics closely integrated with the development teams on trunk  (the main branch).  Beta testing occurs by technologically advanced early adopters after a named milestone release of new features.

Release Cycles

Versions get released as milestone releases which contain new functionality but are indistinguishable from the 'half hourly build' on the time of the release.  These have only been alpha tested by clinics closely related to the development teams who run trunk.  At release no more features or database changes are allowed to the branch unless they are bug fixes.

From a production perspective when there is a branch, for Oscar it is as unstable as the trunk the day it buds (perhaps even more than usual as everyone has just committed code to make the deadline).  You have to give it a little while for the bugs to come out minor nuisance - such as missing tags, or as serious as purple screens of death (PSOD ™ trademarked on behalf of Oscar) when you try a feature.

Its only once the code has stabilized by the programmers after beta testing by early adopters that it is suitable for installation for non technologically inclined users.  In the past this has usually taken a month or so for the code base to settle.

For stability reasons pre-packaged releases run 6 months or so behind a dated version release.  (that is an Ubuntu package for Oscar 10.6 will not be available before 2011)

Commit privileges

CVS changes, bug fixes or other donations of code can/should be submitted to one of the developers to vet.   All submitted code must be released under the GPL in current use by Oscar.  If the developer accepts the code (and responsibility for the commit) they will add it to the project.  Developer status with commit privileges can be extended to (or withdrawn from) individuals by the lead developer in charge of the project on an arbitrary basis.  Getting the developers tired of vetting even more! code from you seems to be a successful stratagem to be extended privileges :-)

Bug Tracking System

Our bug tracking system is on Sourceforge http://sourceforge.net/tracker/?group_id=66701&atid=515432

All and sundry are invited/encouraged to list bugs as they can't be squashed if we are unaware of them.

Browse the list of bugs to ensure that yours is a new one.

As always for best effect be sure to supply  information so that it can be reproduced

• Version/Environment (eg Oscar 10.6 of July 19, 2010 on Ubuntu 10.4 Tomcat 6 MySQL 5 Sun Java 1.6)
• How you got to the bug (eg every time I click on the Inbox ....)
• Screen shot if relevant (eg of missing or malformed labels)
  
• And if possible an excerpt from the Catalina.out logfile found for the default Ubuntu 10.4 Oscar install at /var/lib/tomcat6/logs/catalina.out