documentation

diff --git a/README b/README
new file mode 100644 (file)
index 0000000..a840c8c
--- /dev/null
+++ b/README
@@ -0,0 +1,39 @@
+About
+-----
+
+Matrix is a tool for managing source code packages (or "components") and
+controlling their building and installation.  The packages can either form a
+complete operating system or just an application suite or such.  Other similar
+tools include BitBake (OpenEmbedded), GAR/GARNOME and the ports mechanisms used
+by BSD systems and source-based Linux distributions.
+
+Matrix uses the http://git.or.cz/[Git] version control system for managing the
+components and their meta data.  Component development/maintenance is coupled
+with system integration, which simplifies workflows.  Making a change to a
+component and rebuilding the complete system is easy.  Upgrading to new
+upstream versions or integrating fixes is convenient (even if the upstream
+project doesn't use Git).
+
+Matrix is intended to be used with http://scratchbox.org/[Scratchbox].
+(Support for http://freedesktop.org/wiki/Software/sbox2[Scratchbox 2] is still
+preliminary, but it is intended to be the primarily supported version in the
+future.)  Matrix relies on Scratchbox for cross-compilation and sandboxing; if
+you don't need either (e.g. you want to install applications to your host
+system), you can use Matrix without Scratchbox.
+
+Matrix was developed by http://movial.fi/[Movial] and released under GPL 2 or
+later.  Primary developer contact is Timo Savola <mailto:tsavola@movial.fi[]>.
+
+
+Requirements
+------------
+
+- Scratchbox 1.0 <http://scratchbox.org/[]>
+- Matrix devkit for Scratchbox
+
+or
+
+- POSIX environment (e.g. GNU/Linux)
+- Python 2.3 <http://python.org/[]>
+- Git 1.5 <http://git.or.cz/[]>
+- GNU Make 3.80 <http://www.gnu.org/software/make/[]>

diff --git a/STYLE b/STYLE
new file mode 100644 (file)
index 0000000..ea660ba
--- /dev/null
+++ b/STYLE
@@ -0,0 +1,47 @@
+Python code
+-----------
+
+- Be compatible with Python 2.3.
+
+- Indent with tabs.
+
+- Continuation lines should be indented using tabs up to the indentation
+  level and after that using spaces.  This way the code doesn't visually
+  break with different tab widths.  (If this is too cumbersome, try not to
+  use continuation lines.)
+
+- Try to keep lines short (ideally under 80 characters measured with 8-space
+  tabs).  If a longer line benefits readability, that's fine.  (The longer
+  the line, the better the excuse must be.)
+
+- Import one module per line, and keep imports sorted.  Group system imports
+  and project imports separately.
+
+- Use new-style classes (inherit from `object`).
+
+- Naming: MyClass, my_function, my_method, my_attribute, _my_protected_member,
+  __my_private_member.
+
+- Generally follow the style used in the context you're modifying.  If
+  unsure, follow http://www.python.org/dev/peps/pep-0008/[PEP 8].
+
+
+Makefiles
+---------
+
+- Be compatible with GNU Make 3.80.
+
+
+Shell scripts
+-------------
+
+- Be POSIX-compliant.
+
+
+Documentation
+-------------
+
+- Use http://www.methods.co.nz/asciidoc/[asciidoc] syntax to make the text
+  human- and machine-readable.
+
+- Don't go over 80 characters per line.

diff --git a/TODO b/TODO
new file mode 100644 (file)
index 0000000..b0441b8
--- /dev/null
+++ b/TODO
@@ -0,0 +1,37 @@
+Scratchbox 2 support
+--------------------
+
+- Fix installation in SB2
+- Inject dependencies to packages (for automatic SB2 target setup)
+- Use target-specific build directory for components which support it to enable
+  fast rebuilds when working with multiple targets
+
+
+Packaging and rootfs
+--------------------
+
+- Installed file list generation
+- Add include/exclude rules to component metadata
+- Debian package crationg using file list, include/exclude rules and fakedb
+- Rootfs creation using the packaging information
+- Move device/directory creation from rootfs creation to a component
+- Rootfs generation should support generating multiple image formats at once
+
+
+Documentation
+-------------
+
+- README which describes the purpose of Matrix
+- Example usage/proposed project structure description
+- Internal Python API documentation
+
+
+Miscellaneous
+-------------
+
+- List only top-level target components
+- Standardized version tag for generating source dist and manifests etc.
+- Mechanism and metadata for checking new upstream versions of components
+- Component should be able to force make -j1
+- API documentation build mode
+- Clean up lua-legacy metadata format