reportbug/doc/README.developers

===================================
reportbug's Features for Developers
===================================

(Adapted from original "bug" documentation.)

Bug allows maintainers to control the bug reporting process by placing
files in special places.

Template Information & Interaction with the user
================================================

If /usr/share/bug/$package is executable, then bug executes it and
takes what comes out from the file descriptor 3 and puts it in the bug
template.

The maintainer can then ask questions to the user or run whatever
information gathering script he likes, and echo all the content to fd 3.

e.g.::

	read -p 'color? '
	echo "Color: $REPLY" >&3
	...
	system-information-tool >&3

If /usr/share/bug/$package is a directory, then
/usr/share/bug/$package/script is executed.

While the script is executed, the following shell functions are
available ONLY IF IT IS RUN UNDER /bin/bash::

	getkey				- asks for a key
	yesno <prompt> "yep"|"nop"	- ask for a yes/no answer (with i18n)
					  leaves response as yep or nop
					  in REPLY. The second argument is
					  the default.

If the file /usr/share/bug/$package/presubj exists, its content is
shown to the user before asking him for the bug's subject.

Note: It's your responsibility to check if the information included
in the template can put the user in any security risk.

Package redirection
===================

The package maintainer can control to which packages bug reports are
submitted, by setting the Package: field of the bug report.  This will
be mainly used to redirect bugs in packages coming from a single
source to where the maintainer likes to have them.

This is done by having this line in /usr/share/bug/$package/control::

	Submit-As: $new-package

Note that bug will not check if the $new-package exists as a valid package.

BTS selection
=============

Packages not distributed by Debian can take advantage of this utility too.
They just need to add a "send-to" header to the control file
/usr/share/bug/$package/control::

	Send-To: bugs.myproject.com

``reportbug`` will add ``submit@` ``quiet@`` or ``maintonly@`` to form the address the
bug report mail is send to.

(Note: you probably should use dpkg's support for Origin and Bugs tags
in lieu of this support.)

Nicolás Lichtmaier.-
nick@debian.org

Related packages
================

Often programs are distributed across several different packages, for
example an upstream package 'foo' may be packaged in Debian as foo, libfoo,
foo-common and foo-data.  In such cases it can be useful to include related
package information in bugreports, to minimise the need for 'moreinfo' requests
to the submitter :) This is done by adding a "report-with" header to the
control file::

        report-with: foo libfoo foo-common foo-data

Package information will be added to the bug report for each extra package
listed.

You can also request that the status information for other packages
(that are not dependencies or recommendations) be included with the
report using the "package-status" header::

        package-status: bar baz

Addendum: Languages other than SH
=================================

The script in /usr/share/bug/reportbug/script is an example of a bug
handling script written in Python.  You can also write bug handlers in
many other languages that allow direct access to file descriptors,
including Perl and C/C++.

Note that the getkey and yesno functions are only available in scripts
written using /bin/bash as their interpreter; for other shells or
languages, you will need to write your own input parsing functions.

Source layout
=============

The source tree for ``reportbug`` is organised this way:

* Top level

  * Programs (e.g. ``reportbug``, ``querybts``, etc.).

  * Python library modules, used by the programs.

  * Manual pages.

* Debian packaging

  * ``debian/`` contains the control files used to build the Debian
    source and binary packages.

* `Unit testing framework`_

  * ``test/`` contains the unit test suite. Unit test modules are
    discovered and run using the ``nosetests`` program, and are named
    as ``test_*.py``.

* ?? TODO: describe the purpose

  * ``checks/`` contains ???

* Internationalisation and localisation

  * ``po4a/`` contains configuration and data for localisation of
    source files using the ``po4a`` tool.

Unit testing framework
======================

The reportbug source package now has a unit testing framework.

The directory ``test/`` contains unit test modules and supporting
files. New unit test modules should be added to this directory and
named ``test_*.py``.

The unit test suite depends on the `python-nose` package being
installed, to make the ``nosetests`` command available. The unit tests
themselves can be written using either the `unittest` or `doctest`
modules in the standard Python library.

The `scaffold` module (from the ``test/scaffold.py`` file) contains
some helper functionality for unit tests, including an extended
`TestCase` class.

``make`` targets for testing and quality checks
-----------------------------------------------

The following ``make`` targets are useful for testing and related
tasks.

* ``make test`` runs the unit test suite, preceded by a timestamp
  banner, and reports any test failures or "OK" if all tests pass.

* ``make test-continuous`` starts a loop which clears the screen, runs
  ``make test``, then waits for any of the tests or source code to
  change, and starts the loop again.

  This is useful to run in a separate terminal during a development
  session, so that whenever a change is made the test suite will be
  run automatically. You might want to keep the window hidden while
  actually editing files, and only look at it when you've created or
  modified a file and want to check its effect on the test run.

  This uses the ``inotifywait`` command from the `inotify-tools`
  package to wait for `create` and `modify` events.

* ``make coverage`` runs the test suite and collects test coverage
  information, then reports the current statement coverage of the test
  suite.

  This requires the `python-coverage` package to be installed. See its
  documentation for more about its operation.

* ``make pyflakes`` runs the `pyflakes` static code checker on all
  Python files found in the project tree.

  This requires the `pyflakes` package to be installed. See its
  documentation for more about its operation.

* ``make pylint`` runs the `pylint` code checker on all code modules
  and programs.

  This requires the `pylint` package to be installed. See its
  documentation for more about its operation.


..
    Local Variables:
    coding: utf-8
    mode: rst
    End:
    vim: filetype=rst :