Custom Fields Development (was Re: On Tuesday 28 February 2006 13:58, Myk Melez wrote:)

[Benton, Kevin]

IIRC, the discussion (albeit heated at times) wasn't whether or not to
implement custom fields, but rather how to implement them.  As I recall,
I saw parties going back and fourth about fields as data versus other
methods.  I felt that as long as it was manageable, and didn't
significantly degrade performance of Bugzilla, I didn't really care what
method was used.

---
Kevin Benton
Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator
Digital Media Pervasive Computing Solutions Group
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.

> -----Original Message-----
> From: developers-owner at bugzilla.org
[mailto:developers-owner at bugzilla.org]
> On Behalf Of Luis Villa
> Sent: Wednesday, March 15, 2006 10:53 AM
> To: developers at bugzilla.org
> Subject: Re: On Tuesday 28 February 2006 13:58, Myk Melez wrote:
> 
> On 3/15/06, Gregary Hendricks <ghendricks at novell.com> wrote:
> > 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
> > (at least
> > for bugs). It has a GUI interface for managing the fields, which
show
> > up in all
> > the places listed. And though we don't have support for user fields
> > (not sure
> > what is meant by that), it would probably not be too hard to extend.
> > We offered it back but were told that was not the direction Bugzilla
> > was going.
> 
> If I recall correctly, Greg, the problem was not whether or not to do
> custom fields; I believe the issue was how custom fields were
> implemented in the particular patch that bugzilla.novell.com's work is
> derived from, and that is why the patch was rejected, not disagreement
> with the notion of custom fields.
> 
> Luis
> 
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.benton@amd.com>