Custom Fields again

[Christopher Hicks]

On Thu, 12 Dec 2002, Bradley Baetz wrote:
> No, thats backwards :) I agre that changing the schema is a Big Deal
> (which is part of the reason I don' think that this is a good idea), but
> that doesn't imply that adding a new field should be a Big Deal

All of this worry leads me to feel like we need a better way to manage the
schema.  (Others have touched on this.)  A variety of schemes exist to do
this.  It /shouldn't/ be a big deal for people to add (or drop) fields and
for the software to dynamically figure it out.  Beyond primary keys and
foreign keys there shouldn't be that much that's sacred. Ultimately, I'd
like to see the 'core' schema split into the sacred and optional bits.  
Then local additions and choices regarding the optional core pieces can be 
stored seperately.

I'd recommend looking at Alzabo for managing the schema.  We have been
using an internal system to manage regularly changing schemas and the 
meta-information about each field.  I'm probably going to migrate all of 
that onto Alzabo during our next major development cycle.

> > b) changing your developer's bug tracking process
> 
> Not necessarily. It fact, not usually. You're going to be adding the
> ability to add more information to the bug, and thats about it. How does
> adding a field for the os, or the platform, or for the phase of the
> moon, require a potentially long downtime?

It was mentioned in the URL against custom fields early in this discussion
that the more fields that were added the less likely bugs were to be
submitted.  A number of uses have been mentioned that indicate this isn't
real since for a variety of reasons the bug submitters may never be
exposed to any of these fields.  In our installation we almost totally
ignore the two platform fields even for our software-oriented bugs since
what we're doing is web-oriented and we rarely have any platform-specific
issues.  I'd love to get rid of them, but given the choice of making
changes that will make upgrading harder and ignoring them, it seems easier
to just ignore them.  So, the lack of clean customization seems to impede
our bug tracking process more so than customizability causing problems.

-- 
</chris>

Programming is a Dark Art, and it will always be. The programmer is
fighting against the two most destructive forces in the universe:
entropy and human stupidity. They're not things you can always
overcome with a "methodology" or on a schedule.
		-Damian Conway, Perl God