[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: what needs doing?

	I had something similar going (sorry for not answering before)
regarding this to be able to follow translation's status. The tool I used is
derived from the one used by the French translation team coordinator. You
can take a look at the results by going to
	Feel free to take a look at the WWW's CVS and see how this is
implemente (I sent a message to debian-www some time ago explaining how it
went along and what my ideas where for this).
	The usefulness of this script is that is a simple Perl script, and
the "database" is a hash array. There's an advantage for this comparing it
to your proposal: mirrors do not need to have PostgresSQL, nor access is
needed to a main database.
	However I agree this is a quick fix and I would like it more to have
a scheme as you propose below.

	Since I'm trying to finish my Master Thesis and I want to do it
ASAP, I have laid this idea to rest for the next month (until I finish it),
but I would surely like to see this being done (be it my way or anyother).

	Enough said about my situation I point out below some details on
your schema:

On Tue, May 23, 2000 at 11:20:18PM +1000, skud@netizen.com.au wrote:
> I wouldn't imagine that Wiki was suitable for this.  What you really
> need is something more structured, IMHO.  For instance, a database which
> contained the following:
> Task table
> 	task_id
> 	parent_task (zero if top level)
> 	name
> 	description
> 	URL
> 	urgency (important/normal/wishlist)
> 	degree of completion
> 	technical/developer contact(s)
> Task/package table (links documentation tasks with packages)
> 	task_id
> 	package_name

	What's the reason for this table?
 	Is it to be able to make Debian packages from documents? I would use
a document's table instead. Or do you refer to packages that *need*

> Documentor table
> 	documentor_id
> 	name
> 	email address
> Work table (this shows who's working on what)
> 	task_id
> 	documentor_id

	I would add a table that would be able to have translations
introduce in the DB, something like:

Translation table (which links original documents with their translated

and you forgot the *documents* table:

Document table 
   current state (finished, in revision...)

Document and tasks table
  You should always have *at least* a task 'maintainer' for each document
(unless orphaned)

> ... then a bunch of forms and queries to manipulate and view the data.
> This would let us do such things as "What important pieces of
> documentation are not currently being worked on by anyone?" or "who can
> I talk to about this piece of documentation?" or "what documentation
> tasks are outstanding for these packages?"

	There some things overlooked from this scheme. Like "which package
provides the X document" (like the dwww database). Please note that there
are currently documentation-only packages in Debian (like the doc-debian
package), which we need to have some way to build "automatically" when a
document gets through an edition/revision/stable process.
> I could do a first cut of this in an afternoon in Perl/MySQL.  Using
> PostgreSQL (which I'd have to learn first), call it 2 days.  I do this
> stuff in my sleep, actually... so if there's some kind of consensus that
> people want it done, let me know and I'll do it.

	2 days? Maybe building the tables, but doing the forms would take
much more. How about building an entity-relationship model of the database
(with xfig) and sending it here?

	Best regards


Reply to: