Stalled custom field development

Nick Barnes Nick.Barnes at pobox.com
Fri Apr 1 13:55:46 UTC 2005


At 2005-03-31 21:11:21+0000, Joel Peshkin writes:
> Christopher Hicks wrote:
> 
> > On Wed, 30 Mar 2005, Joel Peshkin wrote:
> >
> >> Actually, it is not paralyzed at all unless someone is foolish enough 
> >> to try to do the whole thing in one huge patch that will never land.
> >
> >
> > When somebody has an existing working implementation it doesn't seem 
> > at all foolish to wish that it could land. 
> 
> 
> The problem is that the existing implementation was incomplete and then 
> effectively abandoned when the data storage schema debate began.

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.

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.  I favour Sean's design because he has a
working deployed implementation of significant size.

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).

Nick B



More information about the developers mailing list