view doc/developers.txt @ 972:ca0a542b2d19

That's gadfly done, mostly. Things left: - Class.filter (I'm a wuss ;) - schema changes adding new non-multilink properties are not implemented. gadfly doesn't have an ALTER TABLE command, making that quite difficult :) I had to mangle two unit tests to get this all working: - gadfly also can't handle two handles open on the one database, so testIDGeneration doesn't try that. - testNewProperty is disabled as per the second comment above. I noticed test_pack was incorrect, and the *dbm tests fail there now. Looking into it...
author Richard Jones <richard@users.sourceforge.net>
date Fri, 23 Aug 2002 04:48:10 +0000
parents 2abb6b2697b6
children 43ab730ee194
line wrap: on
line source

==================
Developing Roundup
==================

:Version: $Revision: 1.3 $

Note: the intended audience of this document is the developers of the core
Roundup code. If you just wish to alter some behaviour of your Roundup
installation, see `customising roundup`_.

.. contents::

Getting Started
---------------

Anyone wishing to help in the development of Roundup must read `Roundup's
Design Document`_ and the `implementation notes`_.

All development is coordinated through two resources:

- roundup-dev mailing list at
  http://lists.sourceforge.net/mailman/listinfo/roundup-devel
- Sourceforge's issue trackers at
  https://sourceforge.net/tracker/?group_id=31577

Small Changes
-------------

Most small changes can be submitted through the Feature tracker, with patches
attached that give context diffs of the affected source.


CVS Access
----------

To get CVS access, contact richard@users.sourceforge.net.


Project Rules
-------------

Mostly the project follows Guido's Style (though naming tends to be a little
relaxed sometimes). In short:

- 80 column width code
- 4-space indentations
- All modules must have a CVS Id line near the top, and a CVS Log at the end

Other project rules:

- New functionality must be documented, even briefly (so at least we know
  where there's missing documentation) and changes to instance configuration
  must be logged in the upgrading document.
- subscribe to roundup-checkins to receive checkin notifications from the
  other developers with CVS access
- discuss any changes with the other developers on roundup-dev. If nothing
  else, this makes sure there's no rude shocks
- write unit tests for changes you make (where possible), and ensure that
  all unit tests run before committing changes
- run pychecker over changed code

The administrators of the project reserve the right to boot developers who
consistently check in code which is either broken or takes the codebase in
directions that have not been agreed to.


-----------------

Back to `Table of Contents`_

.. _`Table of Contents`: index.html
.. _`Customising Roundup`: customizing.html
.. _`Roundup's Design Document`: spec.html
.. _`implementation notes`: implementation.html

Roundup Issue Tracker: http://roundup-tracker.org/