Stalled custom field development

[Joel Peshkin]

Nick Barnes wrote:

>I think this may be at cross-purposes.  Sean has an "existing
>implementation", which he was posting in parts to this list, for
>discussion, which led to the (restart of the) FAC/FAD schema debates.
>I imagine that Christopher Hicks is referring to Sean's implementation
>(certainly it's what I have been referring to in messages with a
>similar sentiment a couple of months ago).
>
>Whereas I assume you are referring to the patches on 91037.  AFAIR
>that bug had good patches for 2.14.* and 2.16.*.  It appears to have
>recently acquired a full patch for 2.18.
>
>  
>
While a patch for 2.18 is handy for the group of people using the patch 
in the unlanded state, the only path that works to land a patch is to do 
it against the tip of cvs and to do it in a manner that actually passes 
muster in terms of  the implementation.  For example, it must work with 
Search and not make a terrible mess of it.  I have not seen a patch come 
for review that does that.  Since I am one of the very few reviewers who 
does review monster patches and I assure you that I will review anything 
that touches Search or security,  that does matter.  Notice that I 
didn't say anything about FAC vs FAD.  Personally, I am happy with either.

>As you point out, the right approach is to break 91037 down into a
>panoply of smaller bugs, as mkanat has started to do.  But hardly any
>of these smaller bugs can get fixed until we have a decision on the
>underlying schema design.
>
That is where we disagree.  Getting the code to "just work" with 
whatever fields are described by fielddefs is a very distinct item not 
blocked by the decision.

>  I favour Sean's design because he has a
>working deployed implementation of significant size.
>
>  
>
I'm happy with either one.  What I don't want to have happen is that we 
go to all of the work of reviewing and testing a patch just to find out 
that myk cannot live with it because of performance concerns  for bmo.  
That would keep it from landing.

>Within a week or two of getting a schema design decision, I expect we
>can get a patch landed for the totally basic first step towards custom
>fields (I outlined before that my idea for this first incremental step
>is a single plain-text field, applicable to all bugs, without any
>layout magic, and which can only be created or customized by hacking
>SQL directly).
>  
>

We almost agree here.  The place I stand is that I think we should 
change the existing code to eliminate the hard-coded fieldlists first 
and then use that mechanism to add custom fields.  The patches I have 
examined to date add a new mechanism that is 90% redundant with 
fielddefs and have a chunk of code after each of the hardcoded loops 
that then add in a special case for the custom fields.  Redundant stuff 
is just a way to create additonal bugs.  If you can accept that point, 
then the difference in our positions is that you want to immediately add 
the first new field (and need a schema decision to do that) and I want 
to have the first step involve no bug schema change.

I would really like to have a customfields implementation land.  mkanat 
and I will work on this as time permits.  It won't take a week or two.  
It will probably take a few months if the interested paries quit 
complaining that justdave hasn't made a ruling on the schema and join in 
on the work.  It will take more like 9-12 months in mkanat and I have to 
do these ourselves.

-Joel