I have an idea for an enhancement to www.mozilla.org/catalog which places a database underneath the catalog and allows us to track when a document was reviewed for accuracy and what Bugzilla bug number applies to that bug. This bug is for creating the database layer in the catalog. The first phase of this bug is for me to create a proposed MySQL database and PHP/XHTML scripts for that database. The second phase of this bug is for jkeiser to translate the PHP scripts into Perl scripts for inclusion as a new tool for mozilla.org.
Reassigning to jkeiser: this has to be written in Perl, my insert query is broken for reasons I don't understand, he's motivated and understands what needs to be done.
Okay, quick summary of a hot debate: It seems better to track our documentation via Zope, except dawn is requiring CVS blame tracking. So our current consensus may be to hack Zope to log into the CVS tree that Mozilla uses, and track our documentation through Zope, with comments showing who's actually doing the changes via CVS.
jkeiser thinks it would be easier and better to build cvs blame natively into Zope. Opinions?
<irc:quote author="jkeiser"> Make Zope Work. runyaga is asking about the easiest way to do the cvs mirroring we want, but given that there are existing CVS impls out there cvsblame should not be a problem. runyaga is going to set some things up on his server, and I'm going to test an install of bonsai to see if I can get it to work. Hmm, mozwebtools would know who knows how to set that up, maybe they could help. The long and short of it--well the short anyway--is that we want to get cvs blame up to keep existing functionality, and that Zope can do everything all of us wants with existing Zope functionality, so we should Go There. </irc:quote>
jkeiser: mind if I take this bug back from you? :) I've recently started reworking my PHP/MySQL approach to the catalog. I currently have a script to dump the current catalog to a MySQL database, and I'm working on tools to maintain it and output the catalog (both in a static page set for those who won't be logging in, and in dynamic pages for those who do log in).
w/ jkeiser's permission.
This isn't really a server ops bug. There's nothing for ops to do until someone has an app written and you need somewhere to install it. Until such time this is just tracking a generic project.
Updating QAContact of all Miscellaneous bugs to email@example.com. If this particular bug should have a different QAContact, please change it and accept my apologies.
This bug is dead, obsolete and buried. ->WONTFIX.