More on custom fields

[Paulo Casanova]

Hi all!

A few weeks ago I posted a mail on custom fields. I'm doing some 
follow-up because the topic came again into discussion (as it comes out 
regularly).

We use bugzilla for software bug tracking (you would never imagine, 
would you? :)) and we have the need for custom fields. My boss, however, 
does not want us to fork much from the bugzilla main development. The 
solution is to aid in the implementation of custom fields in the main 
bugzilla trunk.

I would like to know which of you are willing to form a "taskforce" in 
providing such a hugh patch to bugzilla because that's something that is 
really needed. But I don't think it can be done a single person effort 
because it means *really* a lot of work of both coding, testing and 
reviewing. IMHO it is too "dangerous" to create such a big patch and let 
it lay down in bmo because chances is that it will never get approved 
and then a new release comes out and then we must "remake" the patch and 
then a new release comes out, and ... oh well. You know the story. Just 
need to look at the bug in bmo :)

As a matter of "process" I would suggest:

Phase 0: PLAN
1. We should agree on how to take this. The next phases are my suggestion :)

Phase 1: THINK
1. Let's think about it. What do we want exacly. IMHO "custom fields" is 
too generic as requirement. How extensible?
2. Let's try to separate UI from database. Let's not performance hurt 
features and vice-versa. Usually, in my experience, good designs allow both.
3. Let's give a "real" good look at BZ to see, at least theoretically, 
what can we "convert". Should some fields such as the target milestone, 
flags, status whiteboard, etc. be "converted" to custom fields?
4. Let's give a thought at administration. Command line? UI? Both?

Phase 2: REQUIREMENT DEFINITION
1. OK, let's come up with a written document (is there another form? ;D) 
describing exacly what we want to do and how. Don't forget the migration 
plan, if needed.
2. Get it approved by the BZ development team. Not a patch, no code. 
Just a specification. It will be difficult enough in that form :)

Phase 3: IMPLEMENTATION PLAN
1. Now that we know what we're going to do, let's try to divide the work 
into separate phases. Let's try to get a few basic things in BZ. 
Personally, I think this should not go in as a "whole" patch in once but 
little by little... we should not try to align our plan with BZ's 
release plans. Each phase should end with an accepted path into BZ.

So... are there (still) any voluteers? Or are there any alternative plans?

Paulo