An alternate approach to custom fields

[Sean McAfee]

Bradley Baetz <bbaetz at acm.org> wrote:
>On Fri, Mar 14, 2003 at 07:10:42PM -0500, Sean McAfee wrote:
>> For example, one of our workflows describes the testing path of individual
>> returned parts.  Each part is run through a dozen or more tests.  The result
>> of each test is recorded via a drop-down list on our current system's web
>> interface.  Different tests are performed at different times.  Trying to
>> squeeze all of this information into a single free-form text field and
>> depending on users to keep the field formatted in a way that's suitable
>> for querying seems like a recipe for disaster.

>If the tests are just a pass/fail basis, then you could use keywords or
>(in 2.17) bug flags to represent the various tests. If you sometimes run
>tests more than once, then you'll have to use bug flags.

The keyword approach doesn't seem appropriate.  As I understand it, that
would involve creating a trio of keywords (pass/fail/unknown) for each
possible test, right?  But then there would be no way to prevent these
keywords from being applied to inappropriate incidents, or to enforce
exclusivity.

I didn't know about bug flags, since I've been evaluating 2.16.2.  But I
don't see any mention of them in the 2.17.3 documentation.  How do they
work?

>> In a nutshell, the plan is this:
><snip>

>I suspect that the effort involved in doing that (especially if you want
>to search) is probably more than the effort required to get custom
>fields done properly.
[later]
>The issue with custom fields is not that we don't know how to do it, but
>that none of the developers have time to do it.

Of course, ideally I'd like to have an official, proper custom fields
implementation rather than hacking my own.  But I have a time limit
I'm up against; the license for our existing system expires later this
year--sometime this summer, IIRC.  The custom fields patch has been around
and unfinalized for over a year a half already, with no end in sight, so I
clearly can't depend on it being ready in time.  The advantage to my
approach, as I see it, is that it would be largely independent of the
evolution of the Bugzilla codebase.

Alternately, I could jump in and try to help get custom fields done the
"right" way.  My boss has even suggested that it might be possible to use
some of my at-work time for this.  Is it reasonably possible that a new
developer could bring himself up to speed and drive the completion of an
official custom fields patch in, say, a few months?

-- 
Sean McAfee
etzwane at schwag.org