An alternate approach to custom fields
etzwane at schwag.org
Mon Mar 17 23:24:53 UTC 2003
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
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
>> In a nutshell, the plan is this:
>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.
>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?
etzwane at schwag.org
More information about the developers