The Road to 2.18

[Steven Suson]

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

Sean McAfee wrote:

>I should've jumped in well before now, but I've been ill for the last few
>days.  I'll respond to several messages in this thread at once.
>
>Gervase Markham <gerv at mozilla.org> wrote:
>  
>
>>Mark Davis wrote:
>>    
>>
>>>What are the odds of 91037 making it in to 2.18? 
>>>      
>>>
>
>  
>
>>[That's Custom Fields] Near-zero, I'd say. If any custom fields patch 
>>gets anywhere near getting checked in, I'd want to take the time to take 
>>a long hard look at its architecture. And I'm sure I'm not the only one.
>>    
>>
>
>May I ask, then, what it would take to get an evaluation of my custom fields
>patch of February 13 started?  I'm willing to do whatever it takes to move
>this issue along; make myself available to discuss the architecture;
>whatever.
>
>I think my implementation is very solid.  It's been in use here at my
>workplace (Transmeta) in a production environment since October.  One
>department is using it now; another is set to follow suit this Friday;
>others will adopt it within a few weeks.  As a replacement for the
>bloated, proprietary TeamTrack system we had been shackled to, Bugzilla plus
>my custom field enhancements has been a great success.  I would *dearly*
>love to help roll the patch into the core, not only because I want to give
>back to the community (with Transmeta's blessing, of course, on whose dime I
>created the bulk of the code), but also because it would free me from sole
>responsibility for maintaining the patch.
>
>
>Stuart Donaldson <stu at asyn.com> wrote:
>  
>
>>It would be a big win from the users perspective to get even a partial 
>>solution towards custom fields get into the system for the next release. 
>>This would lock-down a supported schema with a migration path in case 
>>the approach were to change. All these caveats about applying the custom 
>>fields patches because there is "no guarantee that this will be the way 
>>we do it" are holding some people back from trying it out.
>>    
>>
>
>My patch represents such a partial solution.  I've built numerous
>higher-level features on the basic functionality of the patch--transaction
>logging and workflow support, to name the two biggest ones--without changing
>the basic schema.
>
>
>Gervase Markham <gerv at mozilla.org> wrote:
>  
>
>>Indeed. And that's something we want to maintain. Locking down the 
>>schema is to be avoided - because we want to be able to say "actually, 
>>this is all wrong, we want to do it differently."
>>    
>>
>
>Well, one obvious solution is to require that any custom fields schema be
>orthogonal to the basic schema.  My own schema fulfills this condition, save
>for some foreign key references (to PRODUCTS, PROFILES, etc) that are
>ignored by MySQL anyway.
>
>And later:
>
>  
>
>>For a change of this magnitude, it would be wrong to lock down the 
>>schema until the Bugzilla core team has:
>>
>>- decided whether we want custom fields at all
>>    
>>
>
>Is it too much to ask for a definitive answer to this question, soonish?
>
>  
>
>>- if we do, written a design for them
>>    
>>
>
>Must this be done by the core team?  I'd be happy to write a document
>describing the design of my patch.  (Yeah, it's a little bit backwards, I
>know.)
>
>  
>
>>- written the actual patch (either based on existing one, or different)
>>    
>>
>
>Obviously I'm pulling for my own implementation here.
>
>  
>
>>The great thing about Free software is that people can take it in 
>>another direction if they like. That's what the custom fields patch 
>>basically is. If the people maintaining that patch want to set up a 
>>website, or a wiki, or a mailing list, to make it easier for those who 
>>want it to get it, that's fine.
>>    
>>
>
>I'd be happy to do this, if only the status of custom fields would be
>decided one way or the other.
>
>  
>
>>But we won't and can't promise that that 
>>particular patch will get integrated, or that whatever patch does get 
>>integrated will work anything like that one, or that one of us will 
>>write migration code.
>>    
>>
>
>In the case of my patch, no migration code is necessary, thanks to the
>previously-mentioned orthogonality.
>
>
>--Sean
>-
>To view or change your list settings, click here:
><http://bugzilla.org/cgi-bin/mj_wwwusr?user=suson@tuckerenergy.com>
>  
>