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 -- <[EMAIL PROTECTED]> -- 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
