Initial commit of specs repo

The airship-specs repo is for specifications that impact the components
that are part of the airship project group.

Change-Id: Ic72f970f211de95ee0c08616a3a43869270b6061
This commit is contained in:
Bryan Strassner 2018-07-17 11:02:12 -05:00
parent ca404ab799
commit 43b300cdc5
9 changed files with 313 additions and 0 deletions

6
.gitignore vendored Normal file
View File

@ -0,0 +1,6 @@
# Sphinx artifacts
/doc/build/
/doc/*/_static/
!/doc/source/_static/
/AUTHORS
/ChangeLog

20
Makefile Normal file
View File

@ -0,0 +1,20 @@
# Minimal makefile for Sphinx documentation
#
# You can set these variables from the command line.
SPHINXOPTS = -a -E -W
SPHINXBUILD = sphinx-build
SPHINXPROJ = airship-specs
SOURCEDIR = doc/source
BUILDDIR = doc/build
# Put it first so that "make" without argument is like "make help".
help:
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
.PHONY: help Makefile
# Catch-all target: route all unknown targets to Sphinx using the new
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
%: Makefile
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

View File

155
doc/source/conf.py Normal file
View File

@ -0,0 +1,155 @@
# -*- coding: utf-8 -*-
#
# Configuration file for the Sphinx documentation builder.
#
# This file does only contain a selection of the most common options. For a
# full list see the documentation:
# http://www.sphinx-doc.org/en/master/config
# -- Path setup --------------------------------------------------------------
# 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.
#
# import os
# import sys
# sys.path.insert(0, os.path.abspath('.'))
# -- Project information -----------------------------------------------------
project = 'airship-specs'
copyright = '2018, Airship Authors'
author = 'Airship Authors'
# The short X.Y version
version = ''
# The full version, including alpha/beta/rc tags
release = '0.1.0'
# -- General configuration ---------------------------------------------------
# If your documentation needs a minimal Sphinx version, state it here.
#
# needs_sphinx = '1.0'
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = [
]
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# The suffix(es) of source filenames.
# You can specify multiple suffix as a list of string:
#
# source_suffix = ['.rst', '.md']
source_suffix = '.rst'
# The master toctree document.
master_doc = 'index'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
#
# This is also used if you do content translation via gettext catalogs.
# Usually you set "language" from the command line for these cases.
language = None
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
# This pattern also affects html_static_path and html_extra_path .
exclude_patterns = []
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
# -- Options for HTML output -------------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
#
html_theme = 'alabaster'
# 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 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 = ['_static']
# Custom sidebar templates, must be a dictionary that maps document names
# to template names.
#
# The default sidebars (for documents that don't match any pattern) are
# defined by theme itself. Builtin themes are using these templates by
# default: ``['localtoc.html', 'relations.html', 'sourcelink.html',
# 'searchbox.html']``.
#
# html_sidebars = {}
# -- Options for HTMLHelp output ---------------------------------------------
# Output file base name for HTML help builder.
htmlhelp_basename = 'airship-specsdoc'
# -- Options for LaTeX output ------------------------------------------------
latex_elements = {
# The paper size ('letterpaper' or 'a4paper').
#
# 'papersize': 'letterpaper',
# The font size ('10pt', '11pt' or '12pt').
#
# 'pointsize': '10pt',
# Additional stuff for the LaTeX preamble.
#
# 'preamble': '',
# Latex figure (float) alignment
#
# 'figure_align': 'htbp',
}
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title,
# author, documentclass [howto, manual, or own class]).
latex_documents = [
(master_doc, 'airship-specs.tex', 'airship-specs Documentation',
'Airship Authors', 'manual'),
]
# -- Options for manual page output ------------------------------------------
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
(master_doc, 'airship-specs', 'airship-specs Documentation',
[author], 1)
]
# -- Options for Texinfo output ----------------------------------------------
# Grouping the document tree into Texinfo files. List of tuples
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
(master_doc, 'airship-specs', 'airship-specs Documentation',
author, 'airship-specs', 'One line description of project.',
'Miscellaneous'),
]

35
doc/source/index.rst Normal file
View File

@ -0,0 +1,35 @@
.. airship-specs documentation master file, created by
sphinx-quickstart on Tue Jul 10 09:26:57 2018.
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
Airship Specs Documentation
===========================
Proposed Specs
--------------
.. toctree::
:maxdepth: 1
:glob:
specs/*
Approved Specs
--------------
.. toctree::
:maxdepth: 1
:glob:
specs/approved/*
Implemented Specs
-----------------
.. toctree::
:maxdepth: 1
:glob:
specs/implemented/*

1
doc/source/specs Symbolic link
View File

@ -0,0 +1 @@
../../specs

0
specs/approved/.gitkeep Normal file
View File

View File

96
specs/template.rst Normal file
View File

@ -0,0 +1,96 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
.. note::
Blueprints are written using ReSTructured text.
=====================================
Template: The title of your blueprint
=====================================
Introduction paragraph -- What is this blueprint about?
Links
=====
Include pertinent links to where the work is being tracked (e.g. Storyboard),
as well as any other foundational information that may lend clarity to this
blueprint
Problem description
===================
A detailed description of the problem being addressed or solved by this
blueprint
Impacted components
===================
List the Airship components that are impacted by this blueprint
Proposed change
===============
Provide a detailed description of the change being proposed. Include how the
problem will be addressed or solved.
If this is an incremental part of a larger solution or effort, provide the
specific scope of this blueprint, and how it fits into the overarching
solution.
Details of changes to specific Airship components should be specified in this
section, as well as interaction between those components.
Special attention should be given to interfaces between components. New
interfaces shuld attempt to follow established patterns within Airship, or
should be evaluated for suitability as new precedent.
If this blueprint changes testing needs or approaches, that information
should be disclosed here, and should be regarded as part of the deliverable
related to this design.
If this blueprint introduces new functionality that requires new kinds of
documentation, or a change to the documentation processes, that information
should be included in this section.
Security impact
---------------
Details of any security-related concerns that this proposed change introduces
or addresses.
Performance impact
------------------
Analysis of performance changes that are introduced or addressed with this
proposed design.
Alternatives
------------
If other approaches were considered, include a summary of those here, and a
short discussion of why the proposed approach is preferred.
Implementation
==============
If known, include any information detailing assigned individuals, proposed
milestones, intermediate deliverable products, and work items.
If there are Assignee(s) or Work Items, use a sub-heading for that
information.
Dependencies
============
If there are any dependencies on other work, blueprints, or other things that
impact the ability to deliver this solution, include that information here.
References
==========
Any external references (other than the direct links above)