OOFILE | Downloads | Purchasing | Press | Services | Company Information | Soapbox | References | F.A.Q. | HOME 


OOFILE Open Source site and testing DRAFT POLICY


One dimension is the breakdown into areas:

  1. source
  2. test programs
  3. bug reports
  4. documentation

The other dimension is levels of authorisation:

  1. Formally part of an OOFILE release
  2. Informally released from an authorised source (currently only ADSoftware)
  3. Released from an unauthorised source.

I'm considering a feedback mechanism as run by ebay.com where people can accumulate ratings.
(This requires live content, forms and databases on the server!).

Currently version numbers will be supplied as part of formal and informal authorised releases (eg: 1.3b4d11 would be an informal).

Contributors of unauthorised releases are responsible for managing their own suffixes which wil be shown in angle brackets, eg: 1.3b4 <Hump-001>

The combined version number of an unauthorised release should therefore indicate both the base version and a consistent contributor suffix (we will maintain a list).


We guarantee to fix bugs specific to the dBase and c-tree Plus backends which are our commercial products. This guarantee applies to trusted OOFILE releases only.

We may fix bugs in other backends and generic OOFILE code at our discretion.

We guarantee that all bug reports (with possible editing for clarification and public taste) and candidate fixes etc. will be publicised at least as
unauthorised contributions.

Where these fixes involve disclosure of commercial source code (eg: Faircom proprietary code or OOFILE c-tree backend) then we will either password-protect the fixes or only publicise a description of how to change a release to match the fix (eg: via a diff file).

Further support may be available by negotiation. All content received will be regarded as being for public consumption unless marked clearly as confidential!!!!


Bug reports will generally only be accepted if they contain:

  1. a clear description of the problem and how to reproduce it in the
    accompanying sample.
  2. a buildable program including project files. If it requires a
    custom OOFILE release then custom code must be included.
  3. data (if necessary) to reproduce the problem
  4. a copy of the program in 2) already compiled, so it can be checked
    against the version we build. This helps hugely in identifying
    environmental problems!


Be as sloppy as you like. If you can contribute code that shows how to do something, or alternatively shows how we're NOT doing something, great.

Try to write really specific scenarios justifying why you would want a feature - explain how it could be used in an application (mark as
confidential if you don't want publicised).

Try lobbying on the oofile mailing list (join at http://groups.yahoo.com/group/oofile/)to gain support for your idea or flesh out vague wants.


Code will generally only be accepted if accompanied by:

  1. design decision diaries - WHY the change is suggested
  2. a buildable sample program including project files. Preferred is one like our
    console tests that generates its own sample data.
  3. a copy of the program in 2) already compiled, so it can be checked
    against the version we build.
  4. code change diary entries - HOW the change works.


  1. isolate the problem in terms of OOFILE database API manipulations so you
    can write a small console-mode test
  2. ensure that test fails reliably given the original input conditions
    (hard-coding a few data values is a surprisingly quick way to mimic what
    happens in the GUI)
  3. analyze the behaviour to develop a theoretic explanation of why it's
    happening, maybe:
    • it's a bug in core database logic
    • it's a valid input value being used in the wrong circumstance
      (to be noted as a design flaw - we try to improve OOFILE to
      make these harder to create without warnings)
    • it's a bug in the GUI using the core database API.
  4. if it's a real bug in the core database, design changes to eliminate the bug
  5. confirm your changes eliminate the bug
  6. RUN THE REGRESSION TEST SUITE (particularly if the code changes are in core OOFILE database routines, as in this circumstance)

In general, the report writer code and GUI can be considered at the same level as application code in using the OOFILE database API. They don't have any special privileges or access. There are a few things you can do to OOFILE that put it in an invalid state - we're constantly improving the core to make it harder to do this and the current (1.4) version with full Invariant checking is a big step along this path.

However, there will probably still be things that GUI code or user code can do that cause crashes in the core database. Some of these may turn out to be GUI bugs. Some may be bugs in the way the GUI is used.