Greg Smith <greg@2ndQuadrant.com> writes:
> On 06/14/2011 01:16 PM, Robert Haas wrote:
>> But there's no reason that code (which may or may not eventually prove
>> useful) has to be incorporated into the main tree. We don't commit
>> code so people can go benchmark it; we ask for the benchmarking to be
>> done first, and then if the results are favorable, we commit the code.
> Who said anything about this being a commit candidate? The "WIP" in the
> subject says it's not intended to be. The community asks people to
> submit design ideas early so that ideas around them can be explored
> publicly. One of the things that needs to be explored, and that could
> use some community feedback, is exactly how this should be benchmarked
> in the first place. This topic--planning based on cached
> percentage--keeps coming up, but hasn't gone very far as an abstract
> discussion. Having a patch to test lets it turn to a concrete one.
Yeah, it *can't* go very far as an abstract discussion ... we need some
realistic testing to decide whether this is a good idea, and you can't
get that without code.
I think the real underlying issue here is that we have this CommitFest
process that is focused on getting committable or nearly-committable
code into the tree, and it just doesn't fit well for experimental code.
I concur with Robert's desire to not push experimental code into the
main repository, but we need to have *some* way of working with it.
Maybe a separate repo where experimental branches could hang out would
be helpful?
(Another way of phrasing my point is that "WIP" is not conveying the
true status of this patch. Maybe "Experimental" would be an appropriate
label.)
regards, tom lane
