The Road to 2.18 (custom fields)
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
More information about the developers