Re: Improving prep_buildtree used in VPATH builds

On Mon, Sep 27, 2010 at 10:54 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Andrew's question seemed to be about the message-ID.  I agree the
>> topic thing is confusing, though.  I'm wondering if it would be
>> sufficient to do the following - if no topic are available, instead of
>> showing the form, it says something like:
>
>> No topics have been created for this CommitFest yet.  Before adding
>> your patch, you must add one or more items to the <link>topic
>> list</link>.
>
> I liked the idea of pre-populating with the historical set of topics.
> If you encourage the first few submitters to a new CF to invent their
> own topic categories without any guidance, you're going to get some
> crazy topics.

Well, the historical set of topics varies from CommitFest to
CommitFest, by design. There are some that recur pretty regularly, of
course, like Security, Performance, and Miscellaneous. But not every
CF will have a section for ECPG or Refactoring, for example. In one
CF, we may have six ECPG patches, so ECPG gets its own topic; in
another CF, 1 ECPG patch + 2 libpq patches + 1 psql patch get merged
together under a section called Interfaces. This generally makes it
easier to group things in ways that are useful in practice than a
fixed list of topics, so I'm in favor of keeping it that way.

This is surely a surmountable issue but the exact right thing to do is
not altogether obvious to me.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company