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

 

OOFILE Open Source site and testing DRAFT POLICY


OVERALL CONTENT MANAGEMENT

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).


DRAFT SUPPORT POLICY


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!!!!

CONTENT OF BUG REPORTS


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!

CONTENT OF FEATURE SUGGESTIONS


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.

CONTENT OF CODE CONTRIBUTIONS AND FIXES


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.

GUIDE TO DEBUGGING OOFILE CORE DATABASE ISSUES

  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.