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