Re: what needs doing?
On Wed, May 24, 2000 at 11:03:12AM +0200, Javier Fdz-Sanguino Pen~a wrote:
> > 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*
> documentation?
I was thinking of it as the table that relates a documentaiton task with
the package(s) it's documenting. So for intance the documentation for
dpkg would have dpkg listed here. In the case of something like the
packaging manual, the package would be packaging-manual :) In other
cases, the documentation might apply to more than one package, though I
can't think of an example right now.
> 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
> versions)
> document_id
> document_id
>
> and you forgot the *documents* table:
Hrm. What's the difference between a task and a document? Surely a
documentation task *is* a document?
>
> Document table
> document_id
> title
> description
> CVS
> URL
> current state (finished, in revision...)
The only difference between this and the task table, above, is that it
has a CVS field (which is of course an excellent idea).
Now, in the case of translations, they would be sub-tasks of a parent
document. For instance, "Debian FAQ" would have children like "Debian
FAQ French translation". The person who maintains the content of the
Debian FAQ would be the "maintainer" for the parent task, with the head
translator being the "maintainer" for the children tasks.
> > ... 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.
Hrm. Probably useful, yes.
> > 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?
I work insanely fast on things I'm familiar with. For instance, I wrote
a recipe database system of similar complexity last Saturday night, and
a simple calendar subsystem for work's intranet website in about two
hours. I'm not saying it would be *finished*, but it would be a decent
first-cut prototype.
As for xfig, I've never yet been able to figure out how to make the damn
thing work. Not to mention the fact that all my formal education in
things like ER diagrams has degenerated into a kind of psuedo-ER that
may nor may not be what you mean when you use the term. I'd rather
rough it out in text form and throw together a prototype and see what
people think.
K.
--
Kirrily Robert -- <skud@netizen.com.au> -- http://netizen.com.au/
Internet and Open Source Development, Consulting and Training
Level 13, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949 Fax +61 3 9614 0948
Reply to: