Summary: Support selecion session/otk data store. Add redis as data store. Allow admin to select the backend data store. Compatibility matrix: main\/ session>| anydbm | sqlite | redis | mysql | postgresql | anydbm | D | | X | | | sqlite | X | D | X | | | mysql | | | | D | | postgresql | | | | | D | --------------------------------------------------------------+ D - default if unconfigured, X - compatible choice DETAILS roundup/configuration.py: add config.ini section sessiondb with settings: backend and redis_url. CHANGES.txt, doc/admin_guide.txt, doc/installation.txt, doc/upgrading.txt: doc on config of session db and redis. Plus some other fixes: admin - clarified why we do not drop __words and __testids table in native-fts conversion. TYpo fix. upgrading - doc how you can keep using anydbm for session data with sqlite. Fix dupe sentence in an upgrading config.ini section. roundup/backends/back_anydbm.py, roundup/backends/back_sqlite.py: code to support redis, redis/anydbm backends respectively. roundup/backends/sessions_redis.py new storage backend for redis. roundup/rest.py, roundup/cgi/actions.py, roundup/cgi/templating.py redis uses a different way of calculating lifetime/timestamp. Since expiration of an item occurred if its timestamp was more than 1 week old, code would calculate: now - 1 week + lifetime. But this results in faster expiration in redis if used for lifetime/timestamp. Convert code to use the lifetime() method in BasicDatabase that generates the right timestamp for each backend. test/session_common.py: added tests for more cases, get without default, getall non-existing key etc. timestamp test changed to use new self.get_ts which is overridden in other tests. Test that datatypes survive storage. test/test_redis_session.py: test redis session store with sqlite and anydbm primary databases test/test_anydbm.py, test/test_sqlite.py add test to make sure the databases are properly set up sqlite - add test cases where anydbm is used as datastore anydbm - remove updateTimestamp override add get_ts(). test/test_config.py tests on redis_url and compatibility on choice of sessiondb backend .travis.yml: add redis db and redis-py

=========================
Roundup Tracker Templates
=========================

The templates distributed with Roundup are stored in the "share" directory
nominated by Python. On Unix this is typically
``/usr/share/roundup/templates/`` (or ``/usr/local/share...``) and
on Windows this is ``c:\python27\share\roundup\templates\``.

The template loading looks in four places to find the templates:

1. *share* - eg. ``<prefix>/share/roundup/templates/*``.
   This should be the standard place to find them when Roundup is
   installed running setup.py from source.
2. ``install_dir``/../<prefix>/share/....``, where prefix is the
   Python's ``sys.prefix``. ``sys.base_prefix`` or 
   `sys.base_prefix/local``. This finds templates (and locales)
   installed by pip. E.G. in a virtualenv located at (``sys.prefix``):
   ``/tools/roundup``, roundup would be at:
   ``/tools/roundup/lib/python3.6/site-packages/roundup``. The
   templates would be at:
   ``/tools/roundup/lib/python3.6/site-packages/tools/roundup/share/roundup/templates/``.
3. ``<roundup.admin.__file__>/../../share/roundup/templates/*``.
   This will be used if Roundup's run in the distro (aka. source)
   directory.
4. ``<current working dir>/*``.
   This is for when someone unpacks a 3rd-party template.
5. ``<current working dir>``.
   This is for someone who "cd"s to the 3rd-party template dir.

Templates contain:

- modules ``schema.py`` and ``initial_data.py``
- directories ``html``, ``detectors`` and ``extensions``
  (with appropriate contents)
- optional ``config_ini.ini`` file. It is structured like a tracker's
  ``config.ini`` but contains only headers (e.g. ``[main]``) and
  *required* parameters that are different from defaults:
  e.g. ``template_engine = jinja2`` and ``static_files =
  static``. These settings override the default values saved to the
  tracker's ``config.ini``.
- template "marker" file ``TEMPLATE-INFO.txt``, which contains
  the name of the template, a description of the template
  and its intended audience.

An example TEMPLATE-INFO.txt::

 Name: classic
 Description: This is a generic issue tracker that may be used to track bugs,
              feature requests, project issues or any number of other types
              of issues. Most users of Roundup will find that this template
              suits them, with perhaps a few customisations.
 Intended-For: All first-time Roundup users