Re: Improving prep_buildtree used in VPATH builds

On Mon, Sep 27, 2010 at 11:15 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Sep 27, 2010 at 11:08 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> 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.
>>
>> If it's intentional that the topic for the same patch might vary
>> depending on what else is submitted in the same CF, then I think that
>> asking submitters to select topics is the wrong thing from the get-go.
>> The patches should be uncategorized initially, and then someone like the
>> CF manager should group them into topics after-the-fact.
>
> That's actually not a bad idea, although it would require a bit of
> hacking given the way the schema is currently set up.  The current
> system has been working well enough that I'm inclined to do something
> simpler for the present, like maybe just auto-create MIscellaneous for
> each new CF.  That would have more or less the same effect for about
> one-tenth the work.

Eh, on further review, I decided to do something even simpler still,
which is to say unbreak the warning message that's supposed to appear
in this case. Doing one of the things listed above is probably
better, but this took approximately 60 seconds, so let's wait and see
whether it helps. If not, I'll whack it around some more.

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