Re: Feature proposal: distinguish each PostgreSQL instance in the event log - Mailing list pgsql-hackers

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

"Andrew Dunstan" <andrew@dunslane.net> wrote in message 
news:4D889879.3080705@dunslane.net...
>
> 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