Re: Feature proposal: distinguish each PostgreSQL instance in the event log

I'm sorry that I've mistakenly sent an empty mail. This is the intended
mail.

"Andrew Dunstan" <andrew(at)dunslane(dot)net> wrote in message
news:4D889879(dot)3080705(at)dunslane(dot)net(dot)(dot)(dot)
>
> On 03/22/2011 08:22 AM, MauMau wrote:
>> I would appreciate your opinions and advice. I'll try making the patch
>> while I'm waiting for response. I would be very much pleased if I
>> could contribute to PostgreSQL and my proposal could be included in 9.1.
>>
>>
>
> It's a good idea, but 9.1 has been closed for new features for some
> time. This would have to wait for 9.2 I believe.
>
> cheers
>
> andrew
>

OK. I'll try to make a patch for 9.2, considering Tom's advice and opinion.
By that time, I will learn more about PostgreSQL design and source code.

I seem to have misunderstood the commit fest. I've re-read the development
info, and my corrected understanding related to the development cycle is as
follows:

According to the following two pages, now is the commit fest 5. The current
commit fest will end on April 15. I would be grateful if you could tell me
where I can find out that 9.1 is closed for new features.

PostgreSQL 9.1 Development Plan
http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Development_Plan

CommitFest 2011-Next (Open)
https://commitfest.postgresql.org/action/commitfest_view?id=10

Now that the next alpha 5 seems to be the last alpha release for 9.1, and
considering the following description, how should I behave? I don't want to
interrupt your work for release of 9.1.

--------------------------------------------------
Submitting a Patch
http://wiki.postgresql.org/wiki/Submitting_a_Patch
Submission timing
...PostgreSQL development is also organized with periodic CommitFests, which
are periods where new development halts in order to focus on patch review
and committing. It's best if you can avoid sending in a new patch during the
occasional weeks when there is an active CommitFest; you can check the
schedule via the CommitFest application. If your schedule doesn't allow
waiting until an active CommitFest is over, you should explicitly label your
submission as intended for the next CommitFest, not the current one, so that
it's clear it's not intended to be part of the active review process.
--------------------------------------------------

I think the actions I should take are as follows. What is the order of
preference?

1. Wait until the end of current commit fest (possibly April 15), and
continue the discussion and patch submission.
2. Continue the discussion on the func spec and reach agreement as it seems
relatively trivial, but refrain from submitting the patch until the end of
the current commit fest (April 15).
3. Continue the discussion on the func spec and reach agreement as it seems
relatively trivial, and submit the patch to pgsql-hackers and register it
with the current commit fest page. However, the register patch will be
transferred to the first commit fest page for 9.2?
4. Wait until the beginning of 9.2 development and continue the discussion
and patch submission. (But when is it? How can I catch the timing
efficiently?)

Regards
MauMau