prioritizing custom fields development

[Greg Hendricks]

On Tuesday 28 February 2006 13:58, Myk Melez wrote:
> Thanks all for your feedback.  Based on what you've told me and my own
> sense of the project, I've roughly prioritized tasks into the following
> list, where the tasks appearing earlier are higher priority:
>
>     1. custom fields appearance on search, bug list, change multiple
>        bugs, long list, and printable pages;
>     2. ability to list and delete custom fields via the command-line;
>     3. boolean fields;
>     4. web interface for managing custom fields;
>     5. ability to position fields at arbitrary places on the edit
>        bug page;
>     6. type-constrained plain-text fields;
>     7. single-select fields;
>     8. user fields;
>     9. bug fields;
>    10. multi-select fields;
>    11. date fields;
>    12. ability to restrict fields to specific product/component
>        combinations;
>    13. ability to restrict fields to specific user groups;
>    14. multi-user fields;
>    15. multi-bug fields.
>

I am curious about something. At bugzilla.novell.com we implemented a custom 
field patch some time ago. We got the code from one of the custom patch bugs, 
made it into a module, and have been using it since day one. Of the 15 things 
listed here it does almost everything but the command line interface (it has 
a GUI interface for managing). We offered it back and were told that was not 
the direction Bugzilla was going. This was back in the days we had the raging 
debate over custom field implementation.  So my question is, has there been a 
change of direction? Because this seems to be exactly what we have already.

-- 
Greg Hendricks 
Novell IS&T Engineer 
GHendricks at novell.com 
Office: (801) 861-3481 
www.novell.com