The Road to 2.18 - Customfields
bugreport at peshkin.net
Thu Mar 11 17:50:15 UTC 2004
Steven Suson wrote:
> I too perhaps should've posted my two cents worth earlier. There are
> just two things that I wanted to say. One, that when discussing the
> design issues, waiting, etc., that "best is the enemy of good enough."
> And the other, that my company has been waiting approximately a year
> for an extension of functionality to bugzilla, which is FULLY provided
> by custom fields. I pity our poor secretary who is forced to
> supplement our use of bugzilla, using paper and PDF forms. Therefore,
> I heartily support Sean in his efforts.
> Steven Suson
Unfortunately, none of the patches seen to date is "good enough" at
all. The team cannot just merge in a patch that is not written in a
manner that will permit smooth upgrades from version to version, etc..
I agree that we should not require the first customfields patch to do
everything imaginable. There are a base set of design decisions that
need to be agreed to and then a patch, consistent with the standards of
the overall project, can be written an landed. The problem is that
nobody has done that.
I suggest that the following requirements be accepted.....
1) Schema changes must be made by checksetup in the standard way
2) Creation of new fields can be done either using the web (preferred)
3) All activity log functions must still work with customfields. If
this means that the activity log mechansim needs to be replaced, the old
log information must be ported by the upgrade.
4) GUI forms must include custom fields and work, but need not be pretty
5) Possibly in a subsequent release, custom templates should be able to
"hook" custom fields and handle them, overriding the builtin GUI
generation that may be ugly or insufficiently localized.
6) Customfields that are missing from a bug form should never cause an
error or deletion of a customfield when a bug edit is processed.
7) Email notification of customfield changes should work and be selectable.
8) If customfields are product-specific, no information should be lost
on product change, even if the bug is changed to a product that does not
use that field and back again.
9) No really bad SQL should be used. Multiple choices must be handled
by one-to-many relations in the database, not by concatenating multiple
items in strings.
Notice that I didn't even say if I care if the patch supports multiple
datatypes, etc... so long as the schema doesn't preclude adding
additional types later.
Now, if someone writes a real proposal, we can get consensus on it and
go forward. Someone could also skip that step, spend months writing
code, and then get frustrated when the code cannot land.
-Joel [not on anything, especially software]
More information about the developers