summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorSean Finney <seanius@debian.org>2008-06-02 00:14:35 +0200
committerSean Finney <seanius@debian.org>2008-06-02 00:14:35 +0200
commitd84c4c56500e5de9109507cf46476505d4b1d0a9 (patch)
tree58de0ab4b1fe0fbd7dd5ed0c5cb20b5cb7bc6805 /README
downloadpatch-tracker-d84c4c56500e5de9109507cf46476505d4b1d0a9.tar.gz
initial work-in-progress code
Diffstat (limited to 'README')
-rw-r--r--README46
1 files changed, 46 insertions, 0 deletions
diff --git a/README b/README
new file mode 100644
index 0000000..cffbb16
--- /dev/null
+++ b/README
@@ -0,0 +1,46 @@
+welcome to the README file.
+
+--------------------
+setup instructions
+--------------------
+
+required software:
+
+python
+python-cheetah
+python-pygments
+python-debian
+(optional) reprepro
+something providing an httpd
+
+first, you need a partial source archive, with the .dsc, diff.gz, Release,
+and Sources.gz files available. there's a sample config in the subdir
+./reprepro, if you don't have one handy. currently it just fetches a
+few packages for testing, and it also needlessly fetches the orig.tar.gz
+files too, just because i don't know reprepro very well.
+
+so, you have your source archive available, and installed somewhere.
+next set up a web server, and configure it to serve up the "application" from
+wherever, using standard Alias or VirtualHost/DocumentRoot stuff.
+
+next, edit the main python script, gen-patch-info.py. there's a Conf
+class which contains all the configuration stuff that you will need to
+modify to get the script to run and generate pages as it should.
+
+--------------------
+overall design/scheme
+--------------------
+
+currently the plan is to generate static information based on the info
+available in a standard source archive (thus hopefully eliminating the need for
+some kind of complicated tracking infrastructure). The in-between stage
+may involve a lightweight database (i.e. sqlite) for quick/efficient handling
+of source package metadata, but in the current scheme it is all handled
+on the fs directly or within classes. the database shouldn't be necessary
+in the "final output", which is currently static. of course the right is
+reserved for later additions that include dynamic content and/or
+interaction (posting comments to a patch, fetching other data from external
+sources)
+
+the webpages are generated from cheetah based templates in ./templates. if the content is later dynamically generated the templates may still be useful.
+