How to contribute to development
********************************

This is SGPEMv2 Developer Manual (version 1.1, 8 November 2008).

   Copyright (C) 2005-2006 University of Padova, dept. of Pure and
Applied Mathematics

   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no
Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.  A
copy of the license is included in the section entitled "GNU Free
Documentation License".

History
*******

*2006, February 21st, -- Djina Verbanac*
     Added anomaly classes in the subsection anomaly solving process.

*2006, February 7th, -- Matteo Settenvini*
     Added subsection about the anomaly solving process.  Fixed C++
     code conventions about how to document classes, and the note about
     static non-const members in classes.

*2006, February 2nd, -- Luca Vezzaro*
     Updated coding style with a point on static non-POD objects.

*2006, January 27th, -- Matteo Settenvini, Djina Verbanac*
     Add section about conventions to be followed when documenting
     anomalies.

*2006, January 27th, -- Luca Vezzaro*
     Added entry on initialization lists and C-style comments in C++
     Coding Style section.

*2006, January 26th, -- Matteo Settenvini*
     Added reference subsection about documenting code. Added
     decisional and communicative norms.

*2006, January 26th, -- Djina Verbanac*
     Added section about the writing of documentation

*2006, January 24th, -- Luca Vezzaro*
     Updated some code snippets whose style were inconsistent with our
     coding rules. Added the point on operator overloading to the
     coding conventions.

*2005, December 26th, -- Matteo Settenvini*
     Changed directory layout for `src'. Added `swe/prototypes' to
     repository layout.  Added one more convention about C++ header
     files and their licensing.

*2005, December 11th -- Matteo Settenvini*
     Added sources' directory description and repository usage
     guidelines. Included full FDL license text.

*2005, November 8th -- Matteo Settenvini*
     First draft of this document

1 Directory overview
********************

If you need to work on SGPEM sources, you'll probably be interested in
understanding how this package directory structure is organized.

   What follows is the tree you'll find after uncompressing the SGPEM
tar archive.

`config/'
     Files used by Autotools while configuring and compiling SGPEM.

`data/'
     Various data SGPEM will use at runtime, like icons, images, XML
     DTDs, User Interface (`*.ui') definition files, and so on.

`doc/'
     Inside this directory you'll find the User and Developer Manuals,
     like the one you're reading, ready to be compiled.

`desktop/'
     The desktop menu entries for FreeDesktop compliant Desktop
     Environments.

`distro/'
     Files used to prepare a package for a specific platform, maybe
     containing the installer data.

`m4/'
     M4 macros used by Autoconf.

`po/'
     Here are stored the Gettext PO catalogs. If you are a translator,
     you should first look here in order to localize SGPEM into your
     language.

`src/'
     The source files of SGPEM.

2 Writing documentation
***********************

2.1 Formal documents and draft proposals
========================================

2.1.1 Introduction
------------------

For writing and editing technical documents we use a subsection of the
free (as in speech) office suite _OpenOffice.org 2.0.0_, namely
_OpenOffice.org Writer_.

   We sporadically also use other parts of the suite, such as
_OpenOffice.org Calc_ for calculations and charts, and _OpenOffice.org
Impress_ for presentations.

2.1.2 Technical document format
-------------------------------

All technical documents must respect the style and formats explained
hereafter.

   * _All the documents start with a Cover Page_ : The cover page
     contains in the right corner the logo, name and address of the
     company. In the middle of the page there's the title of the
     specific technical document. Under the title goes the acronym of
     the project (SGPEMv2), followed by the version of the document.

     Versions use the format `x.y', where both `x' and `y' are
     integers. Minor changes to the document, like grammatical and
     spelling corrections comport the increment of `y', while structural
     or significant changes (for example, changing the way to resolve a
     specific problem) comport the increment of `x'.

     After the version number, it comes the date of the last
     modification made to the technical document. At the end of the
     cover page it should be reported the status of the document,
     either _Formal_ or _Informal_, followed by one of the tags
     _External_ or _Internal_.

     The footer of the cover page should contain the name of the Author
     of that technical document.

   * The page after the cover page has to contain:

       1.     *Distribution List*: to whom the document goes. It
          includes     the Surname and Name of the person to be reached
          by the document,     along with the role of that person.

       2.     *History of changes*: where to trace the changes made to
          the     document, including the date of the edit, the person
          who made the     change, and the reason(s) of it.

       3.     *List of Approved Versions*: here are traced all the
          approved     versions of the document, reporting the date and
          the name of the     person who approved that particular
          revision.

   * An Abstract has to follow the List of Approved Versions: it's a
     short one-liner of what the document is about.

   * On a new page, there's a Table of Contents that shows all the
     Headings in the file.

     If the document includes a lot of figures, then after the Table of
     Contents there should be an Illustration Index.

   * After that, every document has to start with the Introduction
     section, where it will be described the purpose of the document
     and the purpose of the product, along with a list of used
     References to other documents or resources.

   * Other parts of the document are specific to the technical document
     itself, and therefore should be managed by the editor.  Mostly,
     the general structure for the more common documents can be found at
     `http://www.math.unipd.it/~tullio/IS-1/2005/Progetto/Documenti.html'
     (in Italian).

     In the `docs/misc/' directory of the Subversion repository,
     there's an OpenOffice.org template with some already defined
     styles you should inherit from. Its name is `templatedocument.ott'.

   * At the end of every document there should be a Glossary. The
     Glossary is a file on its own (usually,
     `docs/externals/Glossary.odt' off the repository), so new entries
     must be inserted into this latter.

     Every technical document should "include" the afore mentioned file.
     Please refer to the _OpenOffice.org_ manual about _Sections_ to
     know how to do so. The Glossary will so be linked to the current
     document dinamically, and every change done on the Glossary will
     reflect in an automatic update in every referer.

     In this way all the technical documents are always able to have the
     latest up-to-date and synchronized revision of the Glossary.

   * The Header of all pages, except the one on the cover page,
     contains:

        * in the left corner, the name of the company;

        * in the right corner, the chapter number and name.

   * The Footer of every page, except on the cover page, contains:

        * in the left corner, the title of the document followed by the
          date of the last modification;

        * in the right corner it contains the number of the page due to
          the total number of  pages.

   To make it easier to abide these rules, please remember to inherit
from the template document. It lays down a foundation for all the style
guidelines mentioned above.

2.2 Documenting code
====================

In order to generate documentation straight from the source code:

2.2.1 C++ code
--------------

Please refer to _Doxygen_ manual
(`http://www.stack.nl/~dimitri/doxygen/manual.html') in order to learn
how to use this automatic tool for extracting documentation from code.

   Every function, class, class member, class method, and enumeration
in code should be documented, less of trivial static global functions
visible only to the current compilation unit.

   In particular, for functions and methods, you should use `\param'
and `\return' to describe respectively parameters and return value.

2.2.2 Python code
-----------------

It is usually possible to annotate Python classes so that calling the
`__doc__' method of an object returns its documentation string.  Please
refer to the Python manual at `http://www.python.org/' to learn more of
it.

   However, if we want to generate good documentation straight from
code, with the help of Doxygen, we should use the `#' documenting
style. Please look at the end of
`http://www.stack.nl/~dimitri/doxygen/docblocks.html' for an example.

2.3 Reporting anomalies
=======================

_Note_: sometimes we will refer to an anomaly with the less-formal term
"_bug_".

   Anomaly documentation is divided in two parts. The first part
concerns the Anomaly Investigation and the second one the Anomaly
Resolution.  All informations about anomalies are held in the document
named `AnomalyRecords.odt'. If you find an anomaly you should start a
new page via a page-break, and create a header as follows:

*ID*
     Identification number of the anomaly, a unique integer

*Summary*
     A one-liner with a summary of the anomaly

*Severity*
     This field describes the impact of a bug.

    `Blocker'
          Blocks development and/or testing work

    `Critical'
          crashes, loss of data, severe memory leak

    `Major'
          major loss of function

    `Minor'
          minor loss of function, or other problem where easy
          workaround is present

    `Trivial'
          cosmetic problem like misspelled words or misaligned text

    `Enhancement'
          Request for enhancement

*Anomaly Class*
     This field contains the name of the class to which the anomaly
     belongs to.  There is no need to describe the function of this
     classes, because as you can see the names are self explanatory.

    `Extra (superfluous)'

    `Missing'

    `Ambiguous'

    `Inefficient'

    `Improvement needed'

    `Not conforming to standards'

    `Risk-prone'
          not wrong but there are known, safer, alternative methods

    `Incorrect'

    `Not implementable'

    `Safety'

    `Not adequately documented'

*Reporter*
     Name and email of the person who discovered the anomaly

*Date of Identification*
     Timestamp at which the anomaly was identified

*Milestone*
     The milestone affected by the anomaly (e.g., m0.1)

*Document*
     Document (with version number) affected by the anomaly (e.g.,
     Tecnical Specification, Product Definition, code, documentation,
     ...).

*Status*
     Please choose one and only one of the following states.

     These are used *before* reaching a resolution:

    `UNCONFIRMED'
          This bug has recently been added to the database. Nobody has
          validated that       this bug is true. The manager will
          usually confirm this bug, changing its state       to `NEW',
          but in case the bug existance is quite clear, any stakeholder
               can mark it as such.

          The anomaly may be marked also `RESOLVED' by the manager, if
          it is       `INVALID', `DUPLICATE' or so on, but *not*
          `RESOLVED FIXED'.

    `NEW'
          This bug has recently been added to the assignee's list of
          bugs and must be       processed. Bugs in this state may be
          accepted, and become `ASSIGNED',       passed on to someone
          else, and remain `NEW', or it can be       made also
          `RESOLVED'.

    `ASSIGNED'
          This bug is not yet resolved, but is assigned to the proper
          person. From here       bugs can be given to another person
          and become `ASSIGNED' with a different       assignee, or
          resolved and become `RESOLVED'.

    `REOPENED'
          This bug was once resolved, but the resolution was deemed
          incorrect. For example,       a bug is `REOPENED' when more
          information shows up and the bug is now       reproducible.
          From here bugs are either marked `ASSIGNED' or
          `RESOLVED'.

     Instead, *after* a resolution, the state should change to one of:

    `RESOLVED'
          A resolution has been taken, and it is awaiting verification
          by QA.        From here bugs are either re-opened and become
          `REOPENED', are marked       `VERIFIED', or are closed for
          good and marked `CLOSED'.

    `VERIFIED'
          QA has looked at the bug and the resolution and agrees that
          the       appropriate resolution has been taken. Bugs remain
          in this state until the product       they were reported
          against actually ships, at which point they become `CLOSED'.

    `CLOSED'
          The bug is considered dead, the resolution is correct. Any
          zombie bugs who choose       to walk the earth again must do
          so by becoming `REOPENED'.

*Assigned to*
     Who's working to resolve this anomaly, name and email. Usually,
     it's initially left empty.

*Description and comments*
     Latin creativity at work - text describing the reasons for assuming
     the presence of an anomaly. Please be as clear as possible.
     Unfortunately, giving guidelines in this sense is quite difficult
     ...

     As for follow-ups, always start with the name of the editor, email
     and the timestamp of the comment, assigning a numerical ID to it.
     An example of a comment would be:
          -- Comment #1, Slartibartfast <slarti@go.eu>, 2006 Jan 27th - 16:13 --
          Okay, I'll go and fix the time-space continuum on last Friday 17th.
          Just give me the time to put the gas in my spaceship, will you?

     *Important*: please report it clearly in a new comment if you
     change any field of the anomaly header.

   When the anomaly is resolved, a footer is added to it, with:

*Date*
     Timestamp of the resolution date

*Resolution*
     Choose one and only one of these tags. Please remember to change
     bug state accordingly and to report you've done so in a comment.

    `FIXED'
          A fix for this bug is checked into the tree and tested.

    `INVALID'
          The problem described is not a bug.

    `WONTFIX'
          The problem described is a bug which will never be fixed.

    `DUPLICATE'
          The problem is a duplicate of an existing bug. Marking a bug
          duplicate requires     the bug# of the duplicating bug and
          will at least put that bug number in the     description
          field.

    `WORKSFORME'
          All attempts at reproducing this bug were futile, and reading
          the code produces     no clues as to why the described
          behavior would occur. If more information appears     later,
          the bug can be reopened.

    `MOVED'
          The problem was specific to a related product whose bugs are
          tracked in another     bug database. The bug has been moved
          to that database.

*Fixed by*
     Usually it's the same person as the assignee.

2.3.1 Roles solving anomalies
-----------------------------

When solving an anomaly, we mostly follow the pattern therein explained:

  1. Anybody, having any role, can report an anomaly about the work
     done by someone else.  It doesn't make a lot of sense reporting a
     bug about what you're doing: you just fix it and carry on.

     It may be sensible to report problems about your work only if you
     discover them in a second moment, when you don't cover the same
     role anymore, so the assignee would be different by the reporter.

  2. The discussion starts. Usually the verifier will check the anomaly
     exists, but if enough people confirm the bug, the manager can
     decide to mark the bug as `NEW' as well.

  3. Once it is clear who's the responsible for fixing the anomaly, the
     manager assign the bug to them, marking it as `ASSIGNED'.

  4. A fix/patch may come up from different sources, even by the
     reporter, but only the assignee can apply it to the tree and mark
     the bug as `SOLVED'. They take full responsability of the fix.

  5. The verifier does the needed QA (Quality Assurance), and then
     either reopens the bug or marks it as `VERIFIED'.

  6. When and only if the product ships, a `VERIFIED' anomaly may
     become `CLOSED', by hand of the manager.

3 Coding style
**************

In this chapter we explore some self-imposed coding standards we tried
to follow when coding SGPEM.  If you plan to extend it in any way, you
should conform to the guidelines explained thereafter.

3.1 Editors
===========

IDEs are a bad choice, since usually they leave your directory dirty,
and full of temporary or project files. Please avoid their use if not
strictly necessary.

   A good choice for an editor is GNU Emacs, but every other editor
that both insert spaces instead of tabulation characters and has a good
Unicode support will do.

   Your files should be in "UNIX mode"; that is, only a char is used
for a newline. On DOS-based systems, usually two chars are employed:
the newline char and the carriage return one.  Failure to check your
text files are correctly saved wastes space and others' patience, so
please take care.

   This command usually fixes the problem (_note_: run it as it is only
if no binary files are present in the current directory!):
     for i in *; do tr -d '\r' < $i > $i.d; mv $i{.d,}; done

   Using spaces instead of tabs in indentation is useful to ensure that
your file will be correctly shown if another developer on another
machine opens it with Emacs, Vim, Notepad, or what else he likes. A good
idea is to use an editor which substitutes the <TAB> character with
spaces. Most UNIX editors indent text files cleverly. The tab size is
set to 2, the Emacs default.

   You may want to set `indent-tabs-mode' to `nil' in your
`$HOME/.emacs' initialization file. It's an option you can find via
<M-x> `customize-group fill'.

   GNU Emacs has another nice property: it can automatically indent
code in a whole region for you, with `M-x indent-region'.  Moreover, if
you can get accustomed to it, you can activate the automatic
indentation while in a programming mode, by typing `C-c C-a'.
Experienced programmers find it saves quite a lot of time, but we guess
it's just a matter of taste.

3.2 Coding in C++
=================

SGPEM is mostly written in C++, an Object Oriented language ideated by
Bjarne Stroustrup and standardized in 1998 by ISO.  Here are explained
some guidelines you should keep well in mind if you want to contribute
to this project.

3.2.1 C++ Coding Style
----------------------

These are some notes on coding style, and things you should keep in
mind whenever extending SGPEM source code.  Patches to the source that
don't uniform to these guidelines are likely to be rejected and need
rework.  Coding styles are highly subjective and are often the cause of
harsh holy wars. Here we try also to give a rationale of these choices,
supporting our statements.

  1. Left curly braces go on a newline, respect to the statement that
     comes before them. Right curly braces are to be put into a newline
     too.  It may make you feel uneasy at first, but this behaviour is
     preferable because it clearly let you identify code blocks.
     Moreover, it is observed that putting left curly braces on the
     same line of a statement isn't a rule you always follow: a lot of
     exceptions are raised by particular situations, like: "should my
     brace go on the same line after a class initialization list? and
     after a `for' loop declaration? what happens after namespaces
     declaration?"  So it's best to stick to a well known practice and
     put it always on a newline.  A lot of complex software projects
     follow this rule because it also increases manutenibility: keep in
     mind that you aren't writing code for yourself, but for others to
     read.

  2. The return type for every function goes on a line, while the
     function name and its parameters go on the following, without any
     leading space.  This makes easier to `grep' the source. For
     example, if you're searching for a declaration of `int foo::bar()'
     inside a large directory, grepping for: `'/^foo::bar/g'' will
     immediately pop out the correct result, whereas, if you didn't
     follow this rule, you would have searched for `'/foo::bar/g'',
     thus finding *all* recurrences of the function in the code, even
     function calls.

  3. Use the following example to understand how we want you to space
     expressions:
          ` type var = exp1 OP (exp2 OP fun1(exp3)); '
     And for parameters, the following spacing is preferable:
          ` function(par1, par2 = value, ...)'

  4. Please define pointers like `type* var' instead of `type *var'.

  5. Labels go indented on the same level of the containing code block.
     For example:

          switch(x)
          {
          case 1:
               // foo
          case 2:
               // bar
          default:
               // baz
          }
     Remember that also `public', `protected' and `private' are labels.

  6. Put incomplete class declarations before their interface,
     documenting it. For example:

          /** \brief I'm a useless class
           *
           *  This class is completely useless.
           */
          class C;
                // [...]

          class C
          {
          public:
                // [...]
          };

  7. All header files of the libs and the engine follow a common model.
     Try to adhere to it by looking at existing headers. Document them
     fully, even if it is tedious, using a Doxygen-like syntax. The
     payback will be high, we assure you.

  8. Class names are composed of UpperCamelCase words.  Member
     functions are composed of lowercase words, separated by an
     underscore, since both the STL and Gtk- use this convention.
     Member data are lowercase words (can be separated by an
     underscore).  Enums members are lowercase and they have a prefix
     that tells something about their function, e.g., in an enum named
     _signal_,  "`signal_*;'".  Macro names are written all in capital.

  9. Private member object and function names always begin with an
     underscore. Public and protected ones don't.

 10. Some (broken?) versions of autotools had problems with extensions
     other than `.cc' for C++ implementation files (e.g.  automake
     didn't produce correct implicit rules for them).  Consequently, in
     order to avoid problems, we require you to use the following
     extensions:
        *    `.cc' : C++ implementation files

        *    `.hh' : C++ header files

        *    `.tcc' : Template implementation files

     You can also add to the end of your `~/.emacs' the line:
          `(add-to-list 'auto-mode-alist (cons "\\.tcc\\'" 'c++-mode))'
     to automatically associate the `.tcc' extension to the `c++-mode'.

 11. Constructor initialization list uses the following format:
     C::C(T1 arg1, T2 arg2, ...) :
     	m1(arg1), m2(arg2)...
     {
        //...
     }

3.2.2 C++ Coding Conventions
----------------------------

Some common rules you should keep in mind when writing new code:

  1. Never use `std::cout/cerr' if you can do without them.  Use
     `printf()' and `fprintf()' from `cstdio' instead,so that marking
     strings for `gettext' translation will be easier.

  2. Don't use "`using'" directives into the global space, even in a
     `.cc', and neither in other namespaces. If you don't keep this in
     mind, you're buying to everybody a (big) problem.  "`using'" makes
     sense at the beginning of a function to improve code readability,
     and you should be specific:
       1.  "`using namespace std;'" is bad

       2.  "`using std::string;'" is good

  3. When treating long template names, remember that `typedef' (along
     with `typename' as needed) are your best friends, expecially at
     the beginning of class declarations or function definitions.

  4. "_Syscalls_" are evil for portability.  Thread calls can sometimes
     escape this rule (since they're quite different from system to
     system, and GNU/Linux ones are really good), but remember that
     every UNIX/Win32/Solaris/etc.  native call you use means
     extra-work somewhere in the near future.  If a portable toolkit
     we're using provides the same functionality, it should be
     preferred to a system call.

  5. You should start all your source files, both header and
     implementation ones, with a license notice, like this (no leading
     white lines):

          // path/from/topsrcdir/file.ext - Copyright *<year>*, University
          //                                of Padova, dept. of Pure and Applied
          //                                Mathematics
          //
          // This file is part of SGPEMv2.
          //
          // This is free software; you can redistribute it and/or modify
          // it under the terms of the GNU General Public License as published by
          // the Free Software Foundation; either version 3 of the License, or
          // (at your option) any later version.
          //
          // SGPEMv2 is distributed in the hope that it will be useful,
          // but WITHOUT ANY WARRANTY; without even the implied warranty of
          // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
          // GNU General Public License for more details.
          //
          // You should have received a copy of the GNU General Public License
          // along with SGPEMv2. If not, see http://www.gnu.org/licenses/.
          // Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA

     The style you use to comment this out obviously changes with the
     language you're employing.

  6. Only exportable classes and functions inside a library should be
     marked with correct visibility attribute (usually a macro we
     defined as `SGP_DLLEXPORT'). All the others are marked with
     `--visibility=hidden' from the compiler, and aren't available
     outside the DSO (Dynamic Shared Object) they live in, so that they
     don't clutter the DSO namespace.

  7. When you do something, remember to update the _ChangeLog_. This is
     essential.  More on this on Committing changes.

  8. Remember macros for inclusion at the beginning of header files, as
     well in template implementation files.  In the latter case, you
     may want to include the template implementation files in the
     corresponding header files.  An example of a correct inclusion
     directive is:

          #ifndef HELLO_WORLD_HH
          #define HELLO_WORLD_HH 1

          // interface definitions

          #endif

  9. Please follow this order when declaring a class interface:
       1.        Incomplete declarations of nested classes and
          friend functions / classes declarations.

       2.        Typedefs

       3.        Enums

       4.        Non-static member functions

       5.        Static member functions

       6.        Static constant data members

       7.        Variable data members

          Static non-const public data members shouldn't exist.  Nested
     classes go declared *outside* their containing class. For example:

          class C;

          class C
          {
                class D;
                // ...
          };

          class C::D
          {
                // ...
          };
     The order for visibility should be: `public', then `protected',
     then `private'.

 10. Use operator overloading with care, only define overloaded
     operators if the use of that operator is a natural way to perform
     a particular operation on the object(s).  In case operator
     overloading is considered the best choice, a lot of operators
     should still be avoided due to their profound integration with the
     language, and their tendency to lead to ugly bugs. Some examples
     of these operators are: the casting operator, `operator delete',
     `operator new', `operator ^'.

 11. The C++ standard library is your best friend. For example, if you
     need to allocate some temporary variable on the heap, use an
     `auto_ptr<>' that does the right thing even when an exception is
     raised, and that respects RAII (Resource Acquisition Is
     Initialization).

     Also using extensively algorithms like `for_each' and `copy'
     greatly helps.

 12. Use `glib::ustring' in place of `std::string' as often as
     possible, to ensure Unicode support.

 13. If you need a smart pointer, be sure to check out `glib::RefPtr<>'.

 14. "C-style" comments are useful but are also problematic when you
     need a fast way to exclude code from execution. Since this kind of
     comments cannot nest, C-style comments cannot be used to exclude
     code already commented with these old-way comments. For this
     reason there is no need to complicate our lifes with two styles of
     comments, the C++ comment (//) is more than enough, and typing
     isn't a problem since most editors support batch-commenting for
     multiple lines of code.

 15. Never use global static variables of non-POD (Plain Old Data) type.
     The reason why not doing this is fundamental, and it is well
     described, along with a possible alternative here:
     `http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12'.

4 Committing changes
********************

SGPEM sources are held in a repository managed by Subversion. This is
not an introduction on how to use this tool. For that, you should refer
to its own manual, located at `http://svnbook.red-bean.com/'.  Rather,
it sets some "best practices" you ought to follow committing changes to
the repository.

4.1 Introduction and goals
==========================

The Subversion repository, commonly referred to just as "repository",
is the place where all the material produced within this project will
live.

   There is a strong need to maintain an history of development data,
even on plain documentation, whether it is a proprietary file format
describing an UML chart, or some lovely C source code.

   Mantaining versioned files for everything makes developers more free
to cut, modify, hack, and revamp them, with the safety that older
versions can always be fetched again.

   This document describes some guidelines for maintaining the
repository as clean as possible, by defining some restrictive rules
that developers must respect in order to avoid abusing of the
customizability this tool offers.

4.2 Repository layout
=====================

The layout you'll find inside the repository will be:

`swe/branches'
     This is the same as tags, except that commits are allowed inside
     the branch. Please refer to common development models to decide
     what should or should not be done inside a branch. Note that
     branching isn't something everybody should do: it should be agreed
     together with the project administrator.

     The format of a branch is:
          <_version_number_>-r<_revision_number_>--<_branch_name_>

     Example:
          1.2-r164--guirestyle

`swe/docs'
     (_subdirectories_: `internals', `externals',
      `manuals', `misc')

     Contains all drafts intended for the developers.  This directory
     doesn't support tagging and branching because drafts has "eternal"
     life. If needs arise, they'll rather need to be renamed appending
     their version to their filename (-01, -02, etc.).

`swe/prototypes'
     A number of explorative prototypes we've set up to assess
     availability and workingness of needed technologies.

`swe/tags'
     It contains copies of the `trunk/' directory. Note that tagging
     the trunk directory reflects in a double space only for your local
     working copy, while it is a O(1) operation for the server. Changes
     and commits are NOT allowed here.  Please note that tagging must
     be agreeded with project administrator.

     The format of a tag is:
          <_version_number_>

     Example:
          1.0

`swe/trunk'
     (_subdirectories_: `doc', `src', ...)

     This is the main development area where source files are held.
     Usually, official releases spin off the trunk.  For a list of the
     directories layed out therein, please refer to Directory overview.

4.3 Basic svn usage
===================

In your daily use of the repository you will mostly need to know a very
small subgroup of svn commands. Other ones are usually for fine tuning
operations (like setting file binary flags, keyword expansion, managing
the repository tree, etc.), which are tasks carried out by the
repository administrator.

   Here there's a quick reference about such commands:

`svn checkout _http://svn.gna.org/svn/sgpemv2/trunk_'
     Downloads a copy of the current `drafts/' directory contents.
     Checking out the root repository dir (`swe/') may result, in near
     future, to a *big* download, as branch and tags will be stored
     inside the root directory.

`svn update (_short form_: svn up)'
     Recursively updates the current directory to the latest revision.
     Use option `-r N' to update to a specific revision.

`svn status'
     Shows the status of *your* working copy against the repository.

`svn diff'
     Shows differences in unified diff format between your working copy
     and the base version of the current revision selected (usually it
     means the latest). If you want to compare two different revisions
     you can add a `-r N:M' parameter.

`svn lock _filename_'
     Locks a file so that everybody except the lock owner can't commit
     over it. This is particularly useful for binary files: you should
     always try to acquire a lock before starting editing.

4.4 Gold rules on committing
============================

A versioning system, by definition, records everything that goes
through it.  So it may be a good idea not to commit garbage or make
changes that will probably be rejected by the team. The repository
mustn't be used as a temporary file storage system (so just don't use
it to transfer files from work to home or vice-versa!).

   When you commit something, it should be an acceptable piece of work.
Of course, it can happen that later inspection demonstrates it's better
to revert some changesets, but that's the purpose of having a
centralized versioning system.

   Avoid big commits altogether. A detailed description of your
intentions should hit the mailing list _before_ even starting to write
such a patch. Then, committing your work must happen via *small
incremental patches*.

   Also please avoid making structural tree changes (creating, moving,
removing, renaming directories) without asking first the repository
administrator.

   Everything can be reverted by `svn', but that's not an excuse for
sloppiness.

4.5 How to write good log messages
==================================

Be as descriptive as possible, concisely. If your changeset was
discussed on the mailing list or at a meeting, make a clear reference
to it.

   Please be consistent with the message format. Use a clean english
language, employing only abbreviations contained in the glossary
document.

   Always prepend a dash (-) for each changeset description, followed
by a space. This will make clear, in case of line wrapping, what is
part of the list and what is simply a new line.

   Every sentence must end with a full stop. If a particular description
is composed by several sub-descriptions, use a colon (`:'), and use a
tab space to indent the inner list.

   You can use only one level of nesting for lists. If you need more,
you are probably making an oversized commit.

   An example of the log format is the following:

     - Change description 1.
     - Change description 2:
      <tab>  - Part 1 of change description 2.
      <tab>  - Part 2 of change description 2.
     - Change description 3. This particular change has a very long message
       describing this atomic commit.

4.6 Conflicts resolution
========================

As in any other concurrent development system, conflicts may happen.
this will be demanded to the official `Subversion Book (ch. 3 sect.
5.4)' for an explanation on how to handle them.  We will just quote
something to keep well in mind, however:

     In the end, it all comes down to one critical factor: user
     communication.  When users communicate poorly, both syntactic and
     semantic conflicts increase. No system can force users to
     communicate perfectly, and no system can detect semantic
     conflicts. So there's no point in being lulled into a false
     promise that a locking system will somehow prevent conflicts; in
     practice, locking seems to inhibit productivity more than anything
     else.
   `Version Control with Subversion, a.k.a. "The Subversion Book"'

5 Using the Mailing List
************************

5.1 Introduction and goals
==========================

This mailing list (often referred from now on simply as "ML") has been
created with the specific aim of coordinating the effort of the members
of our Software Engineering steering committee.

   This chapter focuses on describing a set of guidelines of what
should be considered best practices whenever writing to the ML, in
order to avoid possible troubles and thornful outcomes.

   This very chapter (an approved draft) you're reading can be amended
too. For more informations, please refer to the corresponding
subsection, called "A democratic discussion".

5.2 About the language, some useful conventions
===============================================

The English language (either the UK or the US one, but the slangwords)
is believed to be the best choice to deliver our internal drafts and
user manuals, while the external ones are kept in Italian to help our
Customer in his revision work.

   The decision of internally using the English language descends from
two considerations:

   1) English is probably the most widely used language in the world (at
least taking in account geographical extension). Making an effort to use
it correctly during the development of this project is a good training
ground for the future, and makes SGPEMv2 usable also by non-Italian
speakers.

   2) It encourages you to use a cleaner and simplier form, since
you're writing in a foreign language: you actually have to think about
what you're doing in a more careful way; not only to express your
ideas, but also to express your ideas _in a way you can be understood_.
Most people that don't read again what they typed if writing in their
mothertongue, usually look through an email composed in English at
least twice, in order to check out for grammar mistakes. Therefore, it
often makes easier to find also conceptual disasters.

   Please avoid strong words or offensive language. They don't help the
discussion anyway, they represent a waste of bytes on the server, and
at least some of us consider them to be childish behaviour.

   If some of us ask you to explain what you meant, or correct your
grammar, please don't lose your temper or feel blue: we're all here to
learn.

   As a side note, we encourage the use of the "singular they" as a
neutral form. You can find a nice article on this by searching
_Wikipedia_.

   This doesn't forbid you to use Italian for normal communications over
the ML.

5.3 Steer the wheel
===================

Most discussions start with a draft, like this. The talking then goes on
amendating the document and, when no-one opposes it anymore, the draft
is marked as an approved guideline, and everybody is meant to (as
strictly as possible) conform to it.

   Exceptions or revisions to guidelines due to a rework done by some
other process pertain to the KA (Knowledge Area) of Process Improvement
(see SWEBOK §9).

   The committer could ask for some particular modalities in carrying
out this procedure, although unlikely (usually, it's an internal task).

   This draft is hence subject to change in this aspect.

5.4 A democratic discussion
===========================

Of course, not everybody has to agree with everyone else on every
subject. We're just humans, after all; we're entitled to our opinion.
Hence, it may be necessary, at times, to set up a votation.

   In a votation, if `n' options are available, each voter has `n*10'
points expendable. They can thus weight their decision prioritizing one
or more of the listed choices, and distributing these points as they
wish. The highest scoring option wins the votation.  In case of even
scores, ballot can happen until a clear decision has been reached.

   Usually a maximum time to amendate a draft or to vote is declared;
if no further points to discuss are raised in such time, the document
is marked as agreed. The minimum number of days for a votation / to
amend a draft is set to three.

5.5 Keeping the archives clean
==============================

If, by writing your response, you've to comment on things that pertain
to _different_ KAs, or if the discussion requires to be "branched" over
different subjects, please also start a new thread, change the subject
line, and split your own letter, even if the answer to a question just
takes two lines.

   Not only this makes easier to search throughout the archives; it
makes easier for others to reply only to those matters that concern
they, tidily continuing the tree structure of threads.

5.6 Diving in technicalities
============================

E-mails should be sent out text-only, not in HTML format.  This makes
them faster to download, store, manipulate, and it even saves us from
kaki-on-pink kitsch backgrounds.  Moreover, text-only mails are (almost
always) monospaced; this allows the more aestethical-inclined of us to
integrate ASCII-art in them, like handmade diagrams.

   Virtually all email clients available let you choose how you want to
send your messages to a certain address: if in HTML, plain-text or
both. Please choose plain-text only.

   Another important thing to keep in mind, is to set your encoding to
UTF-8. This makes interoperability between different and exotic
encodings possible by using a standard base. Yes, even between different
operating systems, like the one called "98" and the one named "2000"
_;-)_.

   A simple discussion shouldn't be marked in whatever way: it has just
a meaningful subject. For example: _"hello, world!"_ is a bad subject;
it doesn't tell much of the contents of the message, besides that
probably it has some form of salute into it. Also, a line like _"i've a
problem"_ is a bad one: it could be a problem in installing an
operating system, in finding a bug in a program, or in carrying out the
rubbish and feeding the cat.

   An example of a good subject is _"Possible buffer overflow in
recursive-sort.cc:374"_. Also _"How can I stuff my cat with friskies?"_
is a good one, albeit maybe a little bit off topic.

   For documents like this, a subject line of the form _"(draft)
<description>"_ is a good choice. It makes it easily recognizable, and
it's like automatically asking for people to amend.

   Approved drafts are marked with a date, and are copied in a separate
directory of the repository (tipically, a `doc' subdirectory). A quick
TeXinfo rewrite can be performed if need arises, or if someone is
willing to spend five minutes doing so.

   Every approved document contains the full text correctly amended
(whereas, during the discussion just snippets of it are changed by
diff), and starts with a date and a progressive number in its header.
The header should be in the form:

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

     (approved draft) #xxxx, [<area>]
     Initially submitted by: <Name Surname>
     On date: <YYYY, Month DD>
     Approved by:
          <Name Surname 1>
          <Name Surname 2>
          ...
     Rejected by:
          <Name Surname 1>
          ...
     Reason of refusal:
         <description of the reason>
     Finally approved on date: <YYYY, Month DD>

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

   Of course, the `rejected by' list should ideally be empty, or just
listing `nobody'. The subject area is up to the writer to purpose,
wisely. Different areas are instantiated as need arises. Please don't
create a forest of areas; it's no use whatsoever.

   Have fun, and ...

   ... happy hacking!

6 Writing your own plugins
**************************

TODO: write me.

Appendix A License
******************

                   *GNU Free Documentation License*
                      Version 1.2, November 2002

     Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
     51 Franklin St, Fifth Floor, Boston, MA  02110-1301, USA

     Everyone is permitted to copy and distribute verbatim copies
     of this license document, but changing it is not allowed.

  0. PREAMBLE

     The purpose of this License is to make a manual, textbook, or other
     functional and useful document "free" in the sense of freedom: to
     assure everyone the effective freedom to copy and redistribute it,
     with or without modifying it, either commercially or
     noncommercially.  Secondarily, this License preserves for the
     author and publisher a way to get credit for their work, while not
     being considered responsible for modifications made by others.

     This License is a kind of "copyleft", which means that derivative
     works of the document must themselves be free in the same sense.
     It complements the GNU General Public License, which is a copyleft
     license designed for free software.

     We have designed this License in order to use it for manuals for
     free software, because free software needs free documentation: a
     free program should come with manuals providing the same freedoms
     that the software does.  But this License is not limited to
     software manuals; it can be used for any textual work, regardless
     of subject matter or whether it is published as a printed book.
     We recommend this License principally for works whose purpose is
     instruction or reference.

  1. APPLICABILITY AND DEFINITIONS

     This License applies to any manual or other work, in any medium,
     that contains a notice placed by the copyright holder saying it
     can be distributed under the terms of this License.  Such a notice
     grants a world-wide, royalty-free license, unlimited in duration,
     to use that work under the conditions stated herein.  The
     "Document", below, refers to any such manual or work.  Any member
     of the public is a licensee, and is addressed as "you".  You
     accept the license if you copy, modify or distribute the work in a
     way requiring permission under copyright law.

     A "Modified Version" of the Document means any work containing the
     Document or a portion of it, either copied verbatim, or with
     modifications and/or translated into another language.

     A "Secondary Section" is a named appendix or a front-matter section
     of the Document that deals exclusively with the relationship of the
     publishers or authors of the Document to the Document's overall
     subject (or to related matters) and contains nothing that could
     fall directly within that overall subject.  (Thus, if the Document
     is in part a textbook of mathematics, a Secondary Section may not
     explain any mathematics.)  The relationship could be a matter of
     historical connection with the subject or with related matters, or
     of legal, commercial, philosophical, ethical or political position
     regarding them.

     The "Invariant Sections" are certain Secondary Sections whose
     titles are designated, as being those of Invariant Sections, in
     the notice that says that the Document is released under this
     License.  If a section does not fit the above definition of
     Secondary then it is not allowed to be designated as Invariant.
     The Document may contain zero Invariant Sections.  If the Document
     does not identify any Invariant Sections then there are none.

     The "Cover Texts" are certain short passages of text that are
     listed, as Front-Cover Texts or Back-Cover Texts, in the notice
     that says that the Document is released under this License.  A
     Front-Cover Text may be at most 5 words, and a Back-Cover Text may
     be at most 25 words.

     A "Transparent" copy of the Document means a machine-readable copy,
     represented in a format whose specification is available to the
     general public, that is suitable for revising the document
     straightforwardly with generic text editors or (for images
     composed of pixels) generic paint programs or (for drawings) some
     widely available drawing editor, and that is suitable for input to
     text formatters or for automatic translation to a variety of
     formats suitable for input to text formatters.  A copy made in an
     otherwise Transparent file format whose markup, or absence of
     markup, has been arranged to thwart or discourage subsequent
     modification by readers is not Transparent.  An image format is
     not Transparent if used for any substantial amount of text.  A
     copy that is not "Transparent" is called "Opaque".

     Examples of suitable formats for Transparent copies include plain
     ASCII without markup, Texinfo input format, LaTeX input format,
     SGML or XML using a publicly available DTD, and
     standard-conforming simple HTML, PostScript or PDF designed for
     human modification.  Examples of transparent image formats include
     PNG, XCF and JPG.  Opaque formats include proprietary formats that
     can be read and edited only by proprietary word processors, SGML or
     XML for which the DTD and/or processing tools are not generally
     available, and the machine-generated HTML, PostScript or PDF
     produced by some word processors for output purposes only.

     The "Title Page" means, for a printed book, the title page itself,
     plus such following pages as are needed to hold, legibly, the
     material this License requires to appear in the title page.  For
     works in formats which do not have any title page as such, "Title
     Page" means the text near the most prominent appearance of the
     work's title, preceding the beginning of the body of the text.

     A section "Entitled XYZ" means a named subunit of the Document
     whose title either is precisely XYZ or contains XYZ in parentheses
     following text that translates XYZ in another language.  (Here XYZ
     stands for a specific section name mentioned below, such as
     "Acknowledgements", "Dedications", "Endorsements", or "History".)
     To "Preserve the Title" of such a section when you modify the
     Document means that it remains a section "Entitled XYZ" according
     to this definition.

     The Document may include Warranty Disclaimers next to the notice
     which states that this License applies to the Document.  These
     Warranty Disclaimers are considered to be included by reference in
     this License, but only as regards disclaiming warranties: any other
     implication that these Warranty Disclaimers may have is void and
     has no effect on the meaning of this License.

  2. VERBATIM COPYING

     You may copy and distribute the Document in any medium, either
     commercially or noncommercially, provided that this License, the
     copyright notices, and the license notice saying this License
     applies to the Document are reproduced in all copies, and that you
     add no other conditions whatsoever to those of this License.  You
     may not use technical measures to obstruct or control the reading
     or further copying of the copies you make or distribute.  However,
     you may accept compensation in exchange for copies.  If you
     distribute a large enough number of copies you must also follow
     the conditions in section 3.

     You may also lend copies, under the same conditions stated above,
     and you may publicly display copies.

  3. COPYING IN QUANTITY

     If you publish printed copies (or copies in media that commonly
     have printed covers) of the Document, numbering more than 100, and
     the Document's license notice requires Cover Texts, you must
     enclose the copies in covers that carry, clearly and legibly, all
     these Cover Texts: Front-Cover Texts on the front cover, and
     Back-Cover Texts on the back cover.  Both covers must also clearly
     and legibly identify you as the publisher of these copies.  The
     front cover must present the full title with all words of the
     title equally prominent and visible.  You may add other material
     on the covers in addition.  Copying with changes limited to the
     covers, as long as they preserve the title of the Document and
     satisfy these conditions, can be treated as verbatim copying in
     other respects.

     If the required texts for either cover are too voluminous to fit
     legibly, you should put the first ones listed (as many as fit
     reasonably) on the actual cover, and continue the rest onto
     adjacent pages.

     If you publish or distribute Opaque copies of the Document
     numbering more than 100, you must either include a
     machine-readable Transparent copy along with each Opaque copy, or
     state in or with each Opaque copy a computer-network location from
     which the general network-using public has access to download
     using public-standard network protocols a complete Transparent
     copy of the Document, free of added material.  If you use the
     latter option, you must take reasonably prudent steps, when you
     begin distribution of Opaque copies in quantity, to ensure that
     this Transparent copy will remain thus accessible at the stated
     location until at least one year after the last time you
     distribute an Opaque copy (directly or through your agents or
     retailers) of that edition to the public.

     It is requested, but not required, that you contact the authors of
     the Document well before redistributing any large number of
     copies, to give them a chance to provide you with an updated
     version of the Document.

  4. MODIFICATIONS

     You may copy and distribute a Modified Version of the Document
     under the conditions of sections 2 and 3 above, provided that you
     release the Modified Version under precisely this License, with
     the Modified Version filling the role of the Document, thus
     licensing distribution and modification of the Modified Version to
     whoever possesses a copy of it.  In addition, you must do these
     things in the Modified Version:

       A. Use in the Title Page (and on the covers, if any) a title
          distinct from that of the Document, and from those of
          previous versions (which should, if there were any, be listed
          in the History section of the Document).  You may use the
          same title as a previous version if the original publisher of
          that version gives permission.

       B. List on the Title Page, as authors, one or more persons or
          entities responsible for authorship of the modifications in
          the Modified Version, together with at least five of the
          principal authors of the Document (all of its principal
          authors, if it has fewer than five), unless they release you
          from this requirement.

       C. State on the Title page the name of the publisher of the
          Modified Version, as the publisher.

       D. Preserve all the copyright notices of the Document.

       E. Add an appropriate copyright notice for your modifications
          adjacent to the other copyright notices.

       F. Include, immediately after the copyright notices, a license
          notice giving the public permission to use the Modified
          Version under the terms of this License, in the form shown in
          the Addendum below.

       G. Preserve in that license notice the full lists of Invariant
          Sections and required Cover Texts given in the Document's
          license notice.

       H. Include an unaltered copy of this License.

       I. Preserve the section Entitled "History", Preserve its Title,
          and add to it an item stating at least the title, year, new
          authors, and publisher of the Modified Version as given on
          the Title Page.  If there is no section Entitled "History" in
          the Document, create one stating the title, year, authors,
          and publisher of the Document as given on its Title Page,
          then add an item describing the Modified Version as stated in
          the previous sentence.

       J. Preserve the network location, if any, given in the Document
          for public access to a Transparent copy of the Document, and
          likewise the network locations given in the Document for
          previous versions it was based on.  These may be placed in
          the "History" section.  You may omit a network location for a
          work that was published at least four years before the
          Document itself, or if the original publisher of the version
          it refers to gives permission.

       K. For any section Entitled "Acknowledgements" or "Dedications",
          Preserve the Title of the section, and preserve in the
          section all the substance and tone of each of the contributor
          acknowledgements and/or dedications given therein.

       L. Preserve all the Invariant Sections of the Document,
          unaltered in their text and in their titles.  Section numbers
          or the equivalent are not considered part of the section
          titles.

       M. Delete any section Entitled "Endorsements".  Such a section
          may not be included in the Modified Version.

       N. Do not retitle any existing section to be Entitled
          "Endorsements" or to conflict in title with any Invariant
          Section.

       O. Preserve any Warranty Disclaimers.

     If the Modified Version includes new front-matter sections or
     appendices that qualify as Secondary Sections and contain no
     material copied from the Document, you may at your option
     designate some or all of these sections as invariant.  To do this,
     add their titles to the list of Invariant Sections in the Modified
     Version's license notice.  These titles must be distinct from any
     other section titles.

     You may add a section Entitled "Endorsements", provided it contains
     nothing but endorsements of your Modified Version by various
     parties--for example, statements of peer review or that the text
     has been approved by an organization as the authoritative
     definition of a standard.

     You may add a passage of up to five words as a Front-Cover Text,
     and a passage of up to 25 words as a Back-Cover Text, to the end
     of the list of Cover Texts in the Modified Version.  Only one
     passage of Front-Cover Text and one of Back-Cover Text may be
     added by (or through arrangements made by) any one entity.  If the
     Document already includes a cover text for the same cover,
     previously added by you or by arrangement made by the same entity
     you are acting on behalf of, you may not add another; but you may
     replace the old one, on explicit permission from the previous
     publisher that added the old one.

     The author(s) and publisher(s) of the Document do not by this
     License give permission to use their names for publicity for or to
     assert or imply endorsement of any Modified Version.

  5. COMBINING DOCUMENTS

     You may combine the Document with other documents released under
     this License, under the terms defined in section 4 above for
     modified versions, provided that you include in the combination
     all of the Invariant Sections of all of the original documents,
     unmodified, and list them all as Invariant Sections of your
     combined work in its license notice, and that you preserve all
     their Warranty Disclaimers.

     The combined work need only contain one copy of this License, and
     multiple identical Invariant Sections may be replaced with a single
     copy.  If there are multiple Invariant Sections with the same name
     but different contents, make the title of each such section unique
     by adding at the end of it, in parentheses, the name of the
     original author or publisher of that section if known, or else a
     unique number.  Make the same adjustment to the section titles in
     the list of Invariant Sections in the license notice of the
     combined work.

     In the combination, you must combine any sections Entitled
     "History" in the various original documents, forming one section
     Entitled "History"; likewise combine any sections Entitled
     "Acknowledgements", and any sections Entitled "Dedications".  You
     must delete all sections Entitled "Endorsements."

  6. COLLECTIONS OF DOCUMENTS

     You may make a collection consisting of the Document and other
     documents released under this License, and replace the individual
     copies of this License in the various documents with a single copy
     that is included in the collection, provided that you follow the
     rules of this License for verbatim copying of each of the
     documents in all other respects.

     You may extract a single document from such a collection, and
     distribute it individually under this License, provided you insert
     a copy of this License into the extracted document, and follow
     this License in all other respects regarding verbatim copying of
     that document.

  7. AGGREGATION WITH INDEPENDENT WORKS

     A compilation of the Document or its derivatives with other
     separate and independent documents or works, in or on a volume of
     a storage or distribution medium, is called an "aggregate" if the
     copyright resulting from the compilation is not used to limit the
     legal rights of the compilation's users beyond what the individual
     works permit.  When the Document is included in an aggregate, this
     License does not apply to the other works in the aggregate which
     are not themselves derivative works of the Document.

     If the Cover Text requirement of section 3 is applicable to these
     copies of the Document, then if the Document is less than one half
     of the entire aggregate, the Document's Cover Texts may be placed
     on covers that bracket the Document within the aggregate, or the
     electronic equivalent of covers if the Document is in electronic
     form.  Otherwise they must appear on printed covers that bracket
     the whole aggregate.

  8. TRANSLATION

     Translation is considered a kind of modification, so you may
     distribute translations of the Document under the terms of section
     4.  Replacing Invariant Sections with translations requires special
     permission from their copyright holders, but you may include
     translations of some or all Invariant Sections in addition to the
     original versions of these Invariant Sections.  You may include a
     translation of this License, and all the license notices in the
     Document, and any Warranty Disclaimers, provided that you also
     include the original English version of this License and the
     original versions of those notices and disclaimers.  In case of a
     disagreement between the translation and the original version of
     this License or a notice or disclaimer, the original version will
     prevail.

     If a section in the Document is Entitled "Acknowledgements",
     "Dedications", or "History", the requirement (section 4) to
     Preserve its Title (section 1) will typically require changing the
     actual title.

  9. TERMINATION

     You may not copy, modify, sublicense, or distribute the Document
     except as expressly provided for under this License.  Any other
     attempt to copy, modify, sublicense or distribute the Document is
     void, and will automatically terminate your rights under this
     License.  However, parties who have received copies, or rights,
     from you under this License will not have their licenses
     terminated so long as such parties remain in full compliance.

 10. FUTURE REVISIONS OF THIS LICENSE

     The Free Software Foundation may publish new, revised versions of
     the GNU Free Documentation License from time to time.  Such new
     versions will be similar in spirit to the present version, but may
     differ in detail to address new problems or concerns.  See
     `http://www.gnu.org/copyleft/'.

     Each version of the License is given a distinguishing version
     number.  If the Document specifies that a particular numbered
     version of this License "or any later version" applies to it, you
     have the option of following the terms and conditions either of
     that specified version or of any later version that has been
     published (not as a draft) by the Free Software Foundation.  If
     the Document does not specify a version number of this License,
     you may choose any version ever published (not as a draft) by the
     Free Software Foundation.

A.1 _Addendum_: How to use this License for your documents
==========================================================

To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and license
notices just after the title page:

       Copyright (C)  YEAR  YOUR NAME.
       Permission is granted to copy, distribute and/or modify this document
       under the terms of the GNU Free Documentation License, Version 1.2
       or any later version published by the Free Software Foundation;
       with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
       Texts.  A copy of the license is included in the section entitled ``GNU
       Free Documentation License''.

   If you have Invariant Sections, Front-Cover Texts and Back-Cover
Texts, replace the "with...Texts." line with this:

         with the Invariant Sections being LIST THEIR TITLES, with
         the Front-Cover Texts being LIST, and with the Back-Cover Texts
         being LIST.

   If you have Invariant Sections without Cover Texts, or some other
combination of the three, merge those two alternatives to suit the
situation.

   If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License, to
permit their use in free software.