[Tracker-discuss] schema ideas

[Georg Brandl]

Stefan Seefeld schrieb:
> Paul Dubois wrote:
>> FWIW I added a 'Due Date' to our tracker by following the example in the
>> Roundup guide. However, I decided not to use an actual date field but
>> rather strings, so that you can have due dates like "v2.6", "ASAP", and
>> "2Q 2007"; the problem with real dates was that releases do not tend to
>> have stable dates. Using the ordering attribute you can control the
>> order of the groups in a custom search by due date. I added a permission
>> class to give to those special managers allowed to create new 'due dates'.
> 
> The problem I can see with using strings here is that there is nothing
> that enforces a particular value, i.e. if you type 'V1,1' but you actually
> meant 'V1.1' there is no validation, though your bug never shows up if
> you query for all bugs due by release V1.1.
> Using links to join a 'bug' and a 'milestone' (or 'release') table is
> thus less error-prone, and easier to query.

+1. This is also why I'm a bit sceptical about a "tags" value: it's easy to
get the tags wrong, and the bug will then not be found together with the
others belonging to a category.

> (The same would be true if we started to track bugs against particular
> branches, at which point a 'branch' property would probably make sense,
> too.)

I don't think that's needed since we have not so many branches around.
There's at most two maintenance branches, and p3yk.

regards,
Georg