Hi Warren, You mentioned you'd like to implement a database for FE packages. Here are some thoughts for your pondering... I think a very simple solution would be to have two tables. The first would simply be an extension of the current owners.list file. It could still be kept in CVS. Here are the fields that could be in there: Package table: 1. product 2. component 3. description 4. initialowner (current package owner) 5. initialqacontact 6. initialcclist (package co-maintainers) 7. review submitter 8. review submit date 9. reviewer 10. accept date 11. review request BZ ticket number 12. current status (Active, Orphaned, Dropped, Moved to Core) Another table (which could be set alongside the owners.list file, also in CVS) would be automatically maintained by the build system (a row is added each time a build is successfully completed, or maybe when the package is signed) and could look like this: Builds table: 1. component 2. e-v-r 3. fedora release number (devel, 5, 4, etc.) 4. build request submitter 5. build request date Combining the two tables would give an accurate view of the current status of all FE packages, and who did what and at what time. Those tables would be pretty small, and can easily be loaded in any kind of DBMS to extract informations. Keeping the basic data in plain text files allows for easy data input and keeps the update process very plain and open through the commits log in the ml. Cheers, Christian -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list