Developer's Guide to the Code: Difference between revisions

From GCD
Jump to navigation Jump to search
m (Protected "Developer's Guide to the Code" ([edit=sysop] (indefinite) [move=sysop] (indefinite)) [cascading])
Line 9: Line 9:
; database : MySQL migration scripts, schema definitions and scripts involving dumping data in various formats.  The naming scheme for the schema files and migration scripts requires knowledge of the code name sequence and therefore doesn't make much sense.  Henry apologizes for that.
; database : MySQL migration scripts, schema definitions and scripts involving dumping data in various formats.  The naming scheme for the schema files and migration scripts requires knowledge of the code name sequence and therefore doesn't make much sense.  Henry apologizes for that.
; gcd : This was a re-start of the project, intended to supersede the prototype that was developed in the '''pydjango''' tree.  It has what Henry considers to be a better Python package layout.  But then the server went down and the previous admin felt it was better to end support for that system, and we had to resurrect the prototype.  This has useful stuff about the eventual schema direction but is otherwise a dead end.
; gcd : This was a re-start of the project, intended to supersede the prototype that was developed in the '''pydjango''' tree.  It has what Henry considers to be a better Python package layout.  But then the server went down and the previous admin felt it was better to end support for that system, and we had to resurrect the prototype.  This has useful stuff about the eventual schema direction but is otherwise a dead end.
; pydjango :  The "trunk" version of the currently deployed site.  Usually deployed on beta, if it's deployed at all.
; pydjango :  The "trunk" version of the currently deployed site.  Usually deployed on beta, if it's deployed at all.  The '''pydjango''' project was originally a proof-of-concept intended to show that a system written in Python using the Django framework was the right way to go (as opposed to a content management system such as Drupal, or a Microsoft-based solution such as ASP.NET).  Of course, there was a crisis and the prototype ended up in production.  It did get almost entirely rewritten between the initial proof of concept and the production version, but there's still more legacy weirdness than Henry would like to have in a "new" project.


==Python Packages==
==Python Packages==

Revision as of 21:50, 12 September 2010

Overview

This page serves as an introduction to and tour of the GCD code base. It attempts to stay high-level in an effort to avoid becoming out of date immediately as details change. The GCD is implemented as a Django-based web application, using MySQL as a database. Solr is under investigation for search, and at some point we will be using one of the major JavaScript libraries. The general layout is based on what seemed to be Django best practices circa late 2007. Some things might not make much sense, and we'd generally like to fix those, but we have very limited resources and the nature of the server crisis that led to the current code's deployment caused us to accept some choices we might not have otherwise made.

The top level of the SVN tree reflects this:

branches
Various release and development branches of the pydjango tree. One of these is usually deployed on production. The branching strategy is not overly coherent, although Ralf has a proposal for handling future branches that should make more sense.
bugzilla-patch
The GCD uses two different modified versions of Bugzilla 3.0.3- one for tracking data errors and one for technical bugs. This directory holds the patches used to create those versions from a base 3.0.3 installation.
database
MySQL migration scripts, schema definitions and scripts involving dumping data in various formats. The naming scheme for the schema files and migration scripts requires knowledge of the code name sequence and therefore doesn't make much sense. Henry apologizes for that.
gcd
This was a re-start of the project, intended to supersede the prototype that was developed in the pydjango tree. It has what Henry considers to be a better Python package layout. But then the server went down and the previous admin felt it was better to end support for that system, and we had to resurrect the prototype. This has useful stuff about the eventual schema direction but is otherwise a dead end.
pydjango
The "trunk" version of the currently deployed site. Usually deployed on beta, if it's deployed at all. The pydjango project was originally a proof-of-concept intended to show that a system written in Python using the Django framework was the right way to go (as opposed to a content management system such as Drupal, or a Microsoft-based solution such as ASP.NET). Of course, there was a crisis and the prototype ended up in production. It did get almost entirely rewritten between the initial proof of concept and the production version, but there's still more legacy weirdness than Henry would like to have in a "new" project.

Python Packages

Django Templates

CSS Files

Images