= Introduction

This file explains what developers have to do to keep Uttk clean as much as
possible.


= Maintaining Copyright Notices

You may think we don't care much about them, but actually, we will care about
them once we have big problems. Therefore, do understand that we cannot play
with fire here, even though it may seem so benign, or even just painful.

[*Do*]

  * Use Copyright (C) Year1, Year2, Year3 <authors> in any file longer than
    15 lines or so. Include the license below. That includes ChangeLog, README
    and so forth. <authors> must be "Uttk team" for every kernel files and may
    be something else for specific extension such as new strategies, loaders,
    dumpers or filters.
  * Each time you edit a file, update its Copyright dates.
  * To do this automatically with Emacs:
      - add (add-hook 'write-file-hooks 'copyright-update) in your Emacs init
        file,
      - run M-x customize-group Copyright in Emacs, and set the Copyright Query
        value to don't ask.

[*Don't*]

  * Don't use intervals such as Copyright (C) 2001-2003.
  * Don't forget the (C), even though the FSF does not enforce it below.
  * Don't put years for free, just the ones where a file was edited.

The rationale and additional details can be found in a similar document written
by the FSF for its maintainers. The relevant node is Copyright Notices. It
applies to partially to us, but is included below as is. I trust you can see
where adjustments are needed.


= Reviewing Patches

Once the commitment message posted (see Checking in a Revision), it must be
reviewed: every single patch should be reviewed.

The purpose of the review is of course to look for errors, typos, unclear
documentation or ChangeLog, incorrect coding style, or even better
implementation suggestion and so forth.

If there is nothing to report about the patch, just reply «Ok», quoting only
the ChangeLog. Usually the thread ends there.

If there are issues to report, quote only relevant portions of the patch. If
you have several big issues to report, you might want to make separate replies
to split the thread. The author of the patch must answer to these comments,
and if subsequent commits address some of these issues, the reply should refer
to them (e.g., by giving the revision number).

Anybody is welcome to comment a patch, nevertheless, this responsibility
typically falls upon the shoulders of the project maintainer, or the
code-review peer of the author of the patch.


= Releasing

How to make a release of your project.

* Be sure the project is frozen: Ask project manager (if it is not you), look
  at project schedule and news.
* Retrieve the latest development archive (Subversion).
* Hunt FIXMEs.
* Update NEWS file with new version and its major changes. (Ensure the date is
  the date of the release day)
* Update all version numbers (SPEC.yml, documentation, configure.ac ...).
* Review the documentation.
* Review all READMEs files.
* Retrieve final archives and be *sure* all is working fine: rake packages
  (produces a gem package). [1]
* Make these archives available to the public, update download links on your
  website.
* Make public announcement (newsgroups...).
* Make a svn tag. [1]

1: Done by rake release.

--
Uttk's maintainers