=== added directory 'doc'
=== added file 'doc/changes.rst'
@@ -0,0 +1,11 @@
+Version History
+***************
+
+.. _version_2011.11:
+
+Version 2011.11
+===============
+
+.. todo::
+ High level-changelog should be placed here. We should use intersphinx to
+ link to changelogs for particular components
=== added file 'doc/conf.py'
@@ -0,0 +1,204 @@
+# -*- coding: utf-8 -*-
+#
+# LAVA Dashboard documentation build configuration file, created by
+# sphinx-quickstart on Mon Dec 27 16:39:47 2010.
+#
+# This file is execfile()d with the current directory set to its containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys
+import os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+sys.path.append(os.path.abspath('..'))
+
+# -- General configuration -----------------------------------------------------
+
+# Add any Sphinx extension module names here, as strings. They can be extensions
+# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
+extensions = ['sphinx.ext.autodoc', 'sphinx.ext.doctest', 'sphinx.ext.intersphinx', 'sphinx.ext.todo', 'sphinx.ext.coverage']
+
+# Configuration for sphinx.ext.todo
+todo_include_todos = True
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = []
+
+# The suffix of source filenames.
+source_suffix = '.rst'
+
+# The encoding of source files.
+#source_encoding = 'utf-8'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = u'LAVA Server'
+copyright = u'2010-2011, Linaro Limited'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+import versiontools
+import lava_server
+version = "%d.%d" % lava_server.__version__[0:2]
+# The full version, including alpha/beta/rc tags.
+release = versiontools.format_version(lava_server.__version__)
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#language = None
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of documents that shouldn't be included in the build.
+#unused_docs = []
+
+# List of directories, relative to source directory, that shouldn't be searched
+# for source files.
+exclude_trees = []
+
+# The reST default role (used for this markup: `text`) to use for all documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# A list of ignored prefixes for module index sorting.
+#modindex_common_prefix = []
+
+
+# -- Options for HTML output ---------------------------------------------------
+
+# The theme to use for HTML and HTML Help pages. Major themes that come with
+# Sphinx are currently 'default' and 'sphinxdoc'.
+html_theme = 'default'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further. For a list of options available for each theme, see the
+# documentation.
+#html_theme_options = {}
+
+# Add any paths that contain custom themes here, relative to this directory.
+#html_theme_path = []
+
+# The name for this set of Sphinx documents. If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# A shorter title for the navigation bar. Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+#html_logo = None
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = []
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+#html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_use_modindex = True
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+#html_show_sourcelink = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it. The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = ''
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'LAVADocumentation'
+
+
+# -- Options for LaTeX output --------------------------------------------------
+
+# The paper size ('letter' or 'a4').
+#latex_paper_size = 'letter'
+
+# The font size ('10pt', '11pt' or '12pt').
+#latex_font_size = '10pt'
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title, author, documentclass [howto/manual]).
+latex_documents = [
+ ('index', 'LAVAServer.tex', u'LAVA Server Documentation',
+ u'Linaro Validation Team', 'manual'),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+#latex_logo = None
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+#latex_use_parts = False
+
+# Additional stuff for the LaTeX preamble.
+#latex_preamble = ''
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_use_modindex = True
+
+
+# Example configuration for intersphinx: refer to the Python standard library.
+intersphinx_mapping = {'http://docs.python.org/': None}
=== added file 'doc/extending.rst'
@@ -0,0 +1,46 @@
+Adding Extensions to LAVA Server
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+LAVA Server can be used as the base for further extensions. Extensions
+currently exist for things like adding scheduler support, a dashboard
+interface, and additional views of test data. Extensions can add
+further data models, menus, and views, and even APIs to the existing LAVA Server framework.
+
+Extensions are essentially just a django app. It hooks into LAVA Server
+using an entry point called *extensions*.
+
+For a simple example of adding an extension, see the 'demo' subdirectory
+in the lava-server source repository.
+
+setup.py
+********
+
+Your setup.py will need to add entry points for lava_server.extensions
+for the extension you wish to add
+
+.. code-block:: python
+
+ entry_points="""
+ [lava_server.extensions]
+ demo = demo_app.extension:DemoExtension
+ """,
+
+The *DemoExtension* class will be defined below.
+
+LavaServerExtension
+*******************
+The other thing your django extension to LAVA Server will need is a
+class that inherits LavaServerExtensions. This class defines properties
+that are needed for LAVA Server to include your extension.
+
+.. literalinclude:: ../demo/demo_app/extension.py
+
+Extending the API
+*****************
+As previously mentioned, the LAVA Server xmlrpc API can be extended with
+new methods using LAVA Server extensions. In the *demo_app* example we
+have been looking at, a new method called *demoMethod()* is added to the
+API and is automatically added under a namespace called *demo*. It uses
+*ExposedAPI* from *linaro_django_xmlrpc.models* to do this.
+
+.. literalinclude:: ../demo/demo_app/models.py
=== added file 'doc/index.rst'
@@ -0,0 +1,47 @@
+=========================
+LAVA Server Documentation
+=========================
+
+.. warning::
+ This document is *work in progress*.
+
+Features
+========
+The LAVA Server is the core framework used by LAVA web apps. It provides
+the main web interface to LAVA and supports extensions.
+
+
+Indices and tables
+==================
+
+.. toctree::
+ :maxdepth: 2
+
+ installation.rst
+ extending.rst
+ process.rst
+ changes.rst
+
+* :ref:`search`
+
+
+TODO List
+=========
+
+This documentation is not finished (not even close yet). The following list
+contains items that need more work.
+
+.. note::
+ The source code for this document can be found in the lp:lava-project
+ branch. Please contribute patches to make the TODO list shorter.
+
+.. todolist::
+
+
+Questions
+^^^^^^^^^
+.. _questions:
+
+If you have any questions, including to the content of this document, feel free
+to ask them here: https://answers.launchpad.net/lava-project
+
=== added file 'doc/installation.rst'
@@ -0,0 +1,97 @@
+Installation
+^^^^^^^^^^^^
+
+LAVA can be installed in several different ways. As with any open source
+project that does source distribution the end user has all the freedom to do
+what they want. We support certain installation methods more than others. You
+can always ask for support using Launchpad support tracker (see
+:ref:`questions`)
+
+Using virtualenv
+******************
+
+Python Virtualenv is a useful tool for creating a sandbox for working
+with python modules. In Ubuntu, you can get it by installing
+*python-virtualenv* using apt-get. For source and pypi installations of
+non-production systems, it is highly recommended.
+
+Example usage ::
+
+ $ virtualenv sandbox
+ $ cd sandbox
+ $ . bin/activate
+
+Once activated, the environment for that session will be set up so that
+subsequent commands will use the virtual environment settings.
+
+Installation from source
+************************
+
+This is the most complicated and error prone installation method. It requires
+the user to download source release tarballs. Unpack them and install them in
+the correct order. Depending on the exact set of components that are installed
+(especially client or server side components) some additional steps are
+necessary. This may include setting up the web application host (one of many
+possible configurations here), setting up the database (again multiple possible
+options, our recommendation is to use the latest stable version of PostgreSQL).
+
+For installing from source, it's normally much simpler to install from
+pypi first, then update using the source. This is useful if you want
+to use it for development against your own branch. For instance, after
+installing from pypi (see directions below) you could do the following.
+
+Updating in a virtualenv using source ::
+
+ $ bzr branch lp:lava-server
+ $ cd lava-server
+ $ ./setup develop
+
+Installation from PypI
+**********************
+
+PyPi is the python package index (http://pypi.python.org/pypi). It is
+maintained by the python community and is the preferred distribution method
+used by many open source projects written in the python programming language.
+
+Here a front-end program, such as pip (http://pypi.python.org/pypi/pip) is used
+to install packages, and their python dependencies. Pip finds the required set
+of packages, downloads their source releases and does the hard work of figuring
+out the right way to put them together.
+
+This is the best compromise between wide system support (any flavour of Linux,
+OS X and Windows), simplicity, upgrade and availability. The downside is that
+it does not handle, by itself, the last mile. This method does not handle
+things like setting up and running the application server. It also requires the
+user to have additional development packages, such as python header files,
+database server header files, the C compiler and more.
+
+To install using pypi (For development only, not for production)::
+ $ pip install lava-server
+ $ lava-server manage --development syncdb
+ $ lava-server manage --development migrate
+
+You will need to answer a few questions during the syncdb step. This
+will use a simple sqlite database, and should normally only be used for
+testing or hacking on lava-server.
+
+.. todo::
+ Installation instructions for production installations against
+ postgresql using pypi
+
+Installation from PPA
+*********************
+
+This method is only suitable for users running Ubuntu 10.04 or later. Here LAVA
+is pre-compiled and packaged as Debian packages (debs). The installation
+scripts embedded in the packages take care for setting up additional services
+so usually this is the best method to quickly have a self-contained running
+installation. The downside is longer release period as packaging takes
+additional time after each release. Another downside is that our support is
+limited to Ubuntu.
+
+To install using the ppa ::
+
+ $ sudo add-apt-repository ppa:linaro-validation/ppa
+ $ sudo apt-get update
+ $ sudo apt-get install lava-server
+
=== added file 'doc/process.rst'
@@ -0,0 +1,64 @@
+Development process
+===================
+
+LAVA development process is based on Launchpad. If you are not familiar with
+that system you should read the https://help.launchpad.net/ guide first. This
+guide also includes the basics of Bazaar, our version control system of choice.
+
+Most of the work is done by the members of the Linaro Validation Team (you can
+learn more about this team, in particular here:
+launchpad.net/~linaro-validation). Having said that, the code is free and open
+source software, we welcome third party contributions and new team members.
+
+Our team is spread geographically around the world, with some members in
+Europe, America, Asia and Oceania. We are usually talking on our IRC channel
+#linaro.
+
+
+Release process
+^^^^^^^^^^^^^^^
+
+LAVA is being developed on a monthly release schedule. Each release is tagged
+around 20th of each month. We publish all our releases on pypi (for actual
+consumption, packaging, installation, etc.) and Launchpad (for reference).
+
+Launchpad release tarballs are following our YYYY.MM (year, month) pattern.
+Should we need to release an upgrade to any existing release (such as a
+critical bug fix) we append a sequential number preceded by a dash
+(YYYY.MM-NN).
+
+Our PyPi releases use sensible version numbers instead. In general we use
+MAJOR.MINOR.MICRO pattern (where MICRO is omitted when zero). Some components
+are post 1.0, that is they have a major version greater than zero. For such
+components we take extra care to ensure API stability, with sensible transition
+periods, deprecation warnings and more. For other components (that have zero as
+a major release number) our strategy is to keep them compatible as much as
+possible but without ensuring a third party developer code would still work on
+each upgrade.
+
+
+Reporting Bugs
+^^^^^^^^^^^^^^
+
+New bugs can be reported here https://bugs.launchpad.net/lava/+filebug.
+
+If you are not sure which component is affected simply report it to any of the
+LAVA sub-projects and let us handle the rest. As with any bug reports please
+describe the problem and the version of LAVA you ware using.
+
+If you were using our public LAVA instance, the one used by Linaro for daily
+activities (http://validation.linaro.org) try to include a link to a page
+that manifests the problem as that makes debugging easier.
+
+
+Patches, fixes and code
+^^^^^^^^^^^^^^^^^^^^^^^
+
+If you'd like to offer a patch (whether it is a bug fix, documentation update,
+new feature or even a simple typo) it is best to follow this simple check-list:
+
+1. Download the trunk of the correct project
+2. Add your code, change any existing files as needed
+3. Commit in your local branch
+4. Push to launchpad (to the public copy of your branch)
+5. Propose a merge request