The Road to 2.18

[Sean McAfee]

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