6 |
7u83 |
1 |
Website
|
|
|
2 |
=======
|
|
|
3 |
|
|
|
4 |
Currently the focus of the website is as a development resource. In the
|
|
|
5 |
future, it can possibly also serve as a community resource for users,
|
|
|
6 |
point of advocacy, and of course, as a distribution site for the TenDRA
|
|
|
7 |
suite of software.
|
|
|
8 |
|
|
|
9 |
This document provides an overview of intended portions of the website,
|
|
|
10 |
and what they are to contain. This is likely to change as the focus of
|
|
|
11 |
of the site adjusts over time (for example, when marketing/propaganda
|
|
|
12 |
becomes relevant).
|
|
|
13 |
|
|
|
14 |
This is also the first port of call for recruiting new developers; see
|
|
|
15 |
the marketing/newdevelopers document for details.
|
|
|
16 |
|
|
|
17 |
|
|
|
18 |
About
|
|
|
19 |
-----
|
|
|
20 |
|
|
|
21 |
- Project goals
|
|
|
22 |
|
|
|
23 |
The aims of the project, from core principles to subsidiary
|
|
|
24 |
interests.
|
|
|
25 |
|
|
|
26 |
- Philosophy
|
|
|
27 |
|
|
|
28 |
We have a fairly strong philosophy that informs our working
|
|
|
29 |
practice, and influences our goals; this section is to convey
|
|
|
30 |
what it is, and why we use it.
|
|
|
31 |
|
|
|
32 |
- TenDRA history
|
|
|
33 |
|
|
|
34 |
A brief history of how TenDRA came in to being, and the entities
|
|
|
35 |
which have expressed interest - this includes a brief list of
|
|
|
36 |
related projects, in an effort to avoid confusion.
|
|
|
37 |
|
|
|
38 |
- Overview of forthcoming intentions
|
|
|
39 |
|
|
|
40 |
What we intend to be doing over the next phase of development, and
|
|
|
41 |
why. This covers splitting up the project and our refactoring aims
|
|
|
42 |
from a user-facing perspective, to give a better overview of the
|
|
|
43 |
project and how it differs from other projects.
|
|
|
44 |
|
|
|
45 |
- Overview of projects
|
|
|
46 |
|
|
|
47 |
A user-friendly list of our software projects.
|
|
|
48 |
|
|
|
49 |
|
|
|
50 |
Contact
|
|
|
51 |
-------
|
|
|
52 |
|
|
|
53 |
- Mailing lists
|
|
|
54 |
|
|
|
55 |
This is fairly self-explanatory: which lists are available, their
|
|
|
56 |
purposes, how to sign up, and view the archives.
|
|
|
57 |
|
|
|
58 |
- IRC
|
|
|
59 |
|
|
|
60 |
Where we may be found and how to connect us.
|
|
|
61 |
|
|
|
62 |
|
|
|
63 |
User Documentation
|
|
|
64 |
------------------
|
|
|
65 |
|
|
|
66 |
See tendra-doc/user
|
|
|
67 |
|
|
|
68 |
- Suite purpose overview
|
|
|
69 |
|
|
|
70 |
The reasons for each program existing, and what they do from a
|
|
|
71 |
user's perspective. This also includes how they'd fit in to an
|
|
|
72 |
example work-flow, perhaps with some case examples.
|
|
|
73 |
|
|
|
74 |
- Usage guides
|
|
|
75 |
|
|
|
76 |
Details of how to use each program, rather than what the program
|
|
|
77 |
is for. This includes man-page material, as well as the excellent
|
|
|
78 |
guides we inherited.
|
|
|
79 |
|
|
|
80 |
|
|
|
81 |
Download
|
|
|
82 |
--------
|
|
|
83 |
|
|
|
84 |
- Anonymous Subversion access
|
|
|
85 |
|
|
|
86 |
A brief overview of what Subversion is, and details of how to get
|
|
|
87 |
at the source.
|
|
|
88 |
|
|
|
89 |
- Releases
|
|
|
90 |
|
|
|
91 |
An archive of previous releases.
|
|
|
92 |
|
|
|
93 |
|
|
|
94 |
Developer Documentation
|
|
|
95 |
-----------------------
|
|
|
96 |
|
|
|
97 |
See tendra-doc/developer
|
|
|
98 |
|
|
|
99 |
- Subversion organisation
|
|
|
100 |
|
|
|
101 |
How our repository is laid out, and an overview of the protocol for
|
|
|
102 |
branching and tagging.
|
|
|
103 |
|
|
|
104 |
- Suite architecture
|
|
|
105 |
|
|
|
106 |
A conceptual overview of how each piece of software relates to each
|
|
|
107 |
other, from the point of view of working on the source. This does
|
|
|
108 |
not deal with how information flows, rather how the source depends
|
|
|
109 |
on various parts.
|
|
|
110 |
|
|
|
111 |
For details of how each component is written, see the Component
|
|
|
112 |
Guides.
|
|
|
113 |
|
|
|
114 |
- High level design documents
|
|
|
115 |
|
|
|
116 |
These design documents show block-level information flow within each
|
|
|
117 |
program, and give as many conceptual orientation information as
|
|
|
118 |
possible. This is the first port of call when approaching the
|
|
|
119 |
system.
|
|
|
120 |
|
|
|
121 |
- Developer Guides
|
|
|
122 |
|
|
|
123 |
These are introductory task-orientated guides on how to go about
|
|
|
124 |
common procedures, such as adding a new tspec API. See the
|
|
|
125 |
developersguides document for details.
|
|
|
126 |
|
|
|
127 |
- Component Guides
|
|
|
128 |
|
|
|
129 |
Guides on the technical internals of each component. Each of these
|
|
|
130 |
are roughly grouped into the interfaces implemented, and a tour of
|
|
|
131 |
the implementation.
|
|
|
132 |
|
|
|
133 |
- Source code browsing and implementation documentation
|
|
|
134 |
|
|
|
135 |
Whilst this is no substitute for a high-level design or other design
|
|
|
136 |
documentation, this serves sufficiently as implementation
|
|
|
137 |
documentation.
|
|
|
138 |
|
|
|
139 |
DoxyS, or some equivalent source-browsing system will suffice, as
|
|
|
140 |
long as it is capable of showing dependency trees, call graphs, and
|
|
|
141 |
is able to make sense of our helpful directory layout.
|
|
|
142 |
|
|
|
143 |
- Implementation of forthcoming intentions
|
|
|
144 |
|
|
|
145 |
Here we discuss the rationale for future intentions, and the
|
|
|
146 |
details behind implementing them. This includes but is not limited
|
|
|
147 |
to the process of splitting up the source, various refactorings, and
|
|
|
148 |
library designs.
|
|
|
149 |
|
|
|
150 |
- A "todo" list of relativley major items
|
|
|
151 |
|
|
|
152 |
These would generally be too large for single tickets, and might make
|
|
|
153 |
suitable candidates for Google's Summer of Code projects.
|
|
|
154 |
|
|
|
155 |
See development/features for examples.
|
|
|
156 |
|
|
|
157 |
Papers and research articles
|
|
|
158 |
----------------------------
|
|
|
159 |
|
|
|
160 |
One of the longer-term intentions is for TenDRA to provide a platform
|
|
|
161 |
for research. This includes some of the more academic projects, and the
|
|
|
162 |
results of investigations making use of them.
|
|
|
163 |
|
|
|
164 |
|
|
|
165 |
Reference Documentation
|
|
|
166 |
-----------------------
|
|
|
167 |
|
|
|
168 |
Reference materials are the common protocols and APIs which bridge the
|
|
|
169 |
user and development documentation. This includes references for the
|
|
|
170 |
languages such as the TDF and PL_TDF specifications, but is not usage
|
|
|
171 |
references for any particular programs that deal with them.
|
|
|
172 |
|
|
|
173 |
- TDF
|
|
|
174 |
|
|
|
175 |
- PL_TDF
|
|
|
176 |
|
|
|
177 |
|
|
|
178 |
Development
|
|
|
179 |
-----------
|
|
|
180 |
|
|
|
181 |
- Automated build-farm
|
|
|
182 |
|
|
|
183 |
We're planning an automated build-farm system, in the style of
|
|
|
184 |
PostgreSQL's farm. This will provide automated compilation on as
|
|
|
185 |
many different platforms as we can find, and show their status.
|
|
|
186 |
|
|
|
187 |
This section should also describe how to participate in the farm.
|
|
|
188 |
|
|
|
189 |
- Trac components
|
|
|
190 |
|
|
|
191 |
Trac provides a central point for several aspects of development.
|
|
|
192 |
These include:
|
|
|
193 |
|
|
|
194 |
- Timeline
|
|
|
195 |
|
|
|
196 |
- Tickets
|
|
|
197 |
|
|
|
198 |
- Source browser (to be modified to link to DoxyS)
|
|
|
199 |
|
|
|
200 |
- Automated builds
|
|
|
201 |
|