Working on sbuild                                                   -*- text -*-
═════════════════

This document is a short guide to the conventions used in the
buildd-tools sbuild project.


Coding
──────

The style should be apparent from the source.  It is the default Emacs
perl-mode style.


Documentation
─────────────

All the documentation is in UNIX manual page format.  GNU roff
extensions are permitted, as is use of tbl.  Make sure the printed
output is as good as terminal display.  Run "make ps" or "make pdf" to
build the printed documentation.


The following styles are used:

  Style                  Formatting                Syntax
  --------------------------------------------------------------------
  New term               Bold                      .B or \fB
  Option definition      Bold, args in italic      .BR and \fI
  Option reference       Italic                    .I or \fI
  File definition        Bold italic               \f[BI]
  File reference         Italic                    .I or \fI
  Config key definition  Courier bold italic       \f[CBI]
  Config key reference   Courier italic            \f[CI]
  Values                 Single quotes             \[oq] and \[cq]
  Example text           Double quotes             \[lq] and \[rq]
  Cross references       Italics in double quotes  \[lq]\fI...\fP\[rq]
  Verbatim examples      Courier                   \f[CR]
  Verbatim user input    Courier bold              \f[CB]


Releasing
─────────

New upstream releases:

• The code must pass the testsuite (run 'sudo make check' after
  ./configure --enable-chroot-checks). This requires a local schroot
  called 'unstable' setup. These checks can take some time to
  run. Plain "autoreconf -fi && ./configure && make check" runs only the
  checks that can be done without schroot, which are very quick.

• Add an entry for the new version into ChangeLog.in. Do not add entries to
  ChangeLog.in together with the implementation of the feature because that
  makes it harder to rebase these commits.

• Adjust the VERSION file with the new sbuild version and the release date.

• Run scripts/git-tag-release which will tag the git repository and
  prompt for a GPG passphrase to sign the tag with your GPG public
  key.

• Run scripts/git-archive to generate the release tarball.

New Debian releases:

• Switch the branch to debian/unstable

• Create a commit "import upstream version XXX" by doing:
    - rm -rf *
    - tar --strip-components=1 -xf ../sbuild-XXX.tar.xz
    - git checkout -- debian
    - git add .
    - git commit -m "import upstream version XXX"

• Create a commit "release XXX-1 to unstable" by doing:
    - dch --newversion XXX-1
    - adding all new entries from ChangeLog.in to debian/changelog
    - add bugnumbers to the items as required
    - go through $(git log master) to add any other entries that
      closed bugs
    - check $(bts select package:sbuild tag:pending) for any
      other bugs that need to be closed by this release
    - run git add and "git commit -m 'release XXX to unstable'"

• Rename ../sbuild-XXX.tar.xz to ../sbuild_XXX.orig.tar.xz and
  use it to build and test the package.

• Run $(dch -r && git add debian/changelog && git commit --amend)

• Run debian/git-tag-debian in the git source to tag the debian
  release.
