Greetings all, Elliot in particular,
I started to parse the owners.list file in preparation for setting up some sort of ACL system on the new VCS and decided to look into how this is going to interact with the PackageDB. For starters, I took the TurboGears schema that Elliot posted and added comments.
Are the comments in this file accurate? Can you explain what the "status" fields in the *History classes represent?
-Toshio
On 29/08/2006, at 01:13 AM, Toshio Kuratomi wrote:
Greetings all, Elliot in particular,
I started to parse the owners.list file in preparation for setting up some sort of ACL system on the new VCS and decided to look into how this is going to interact with the PackageDB. For starters, I took the TurboGears schema that Elliot posted and added comments.
Are the comments in this file accurate? Can you explain what the "status" fields in the *History classes represent?
It tells you the new status of the item at that point in history. For example, this lets you tell who changed a package from 'UNDER_REVIEW' to 'APPROVED', and when.
Best, -- Elliot
On Mon, 2006-09-04 at 15:55 -0400, Elliot Lee wrote:
On 29/08/2006, at 01:13 AM, Toshio Kuratomi wrote:
Are the comments in this file accurate? Can you explain what the "status" fields in the *History classes represent?
It tells you the new status of the item at that point in history. For example, this lets you tell who changed a package from 'UNDER_REVIEW' to 'APPROVED', and when.
Ah. Any reason not to combine that with the "action" column?
-Toshio
On 05/09/2006, at 01:46 AM, Toshio Kuratomi wrote:
On Mon, 2006-09-04 at 15:55 -0400, Elliot Lee wrote:
On 29/08/2006, at 01:13 AM, Toshio Kuratomi wrote:
Are the comments in this file accurate? Can you explain what the "status" fields in the *History classes represent?
It tells you the new status of the item at that point in history. For example, this lets you tell who changed a package from 'UNDER_REVIEW' to 'APPROVED', and when.
Ah. Any reason not to combine that with the "action" column?
There are some actions (currently add and delete) that don't affect the status. Overloading the action column to store the status as well doesn't seem particularly clean to me, but I suppose it could be done.
The "right" way to do things might be to serialize the whole object into history records, instead of trying to copy parts of its state into the history fields.
Best, -- Elliot
infrastructure@lists.fedoraproject.org