The Road to 2.18 (custom fields)

Stuart Donaldson stu at asyn.com
Mon Mar 8 18:14:43 UTC 2004


Due to the size and impact of the Custom Fields work, it sounds like it 
would be good if this can be broken down into smaller pieces.

Is it reasonable to break this down into smaller parts?

Would it make sense to break it into:

a) Schema change & Field definnition
b) Placing fields on the bug page
c) Adding selectable fields to the buglist
d) Simple searching on custom fields (any custom field contains x)
d) Advanced searching on custom fields (specify field=x)

This is just a quick stab at a breakdown to illustrate the concept.

Now of course you want to understand the searching issues in order to 
evaluate the Schema, but we don't have to have a fully debugged 
implementation of searching.

If (a) above can be agreed to, then compatibility with future releases 
becomes much easier to maintain. I am no longer worried about 
implementing custom field patches that address the searching, or the 
buglist, or any other issues, because I know my database schema will be 
supported at least in a migration sense in the future.

Would it help if the this were broken out in a manner similar to what I 
listed above? Likely a better breakdown of phases exists, but the 
concept remains.

Regards,

-Stuart-



More information about the developers mailing list