[pgpool-general: 3044] Re: Release schedule / next 3.3.x stable?

[Tatsuo Ishii]

> On Thu, Jul 17, 2014 at 6:16 AM, Tatsuo Ishii <ishii at postgresql.org> wrote:
>>> Ok, thank you for the reply.
>>>
>>> We use Postgres 9.3 (two nodes in streaming replication) and pgpool
>>> 3.3.3-3 (doing virtual IP failover).  I am happy to try testing
>>> patches, but without a repro that's hard.
>>>
>>> Using your SRPM, I built a new RPM from V3_3_0_STABLE.
>>
>> A patch trying to fix the problem was attached at the mantis issue
>> entry. So you could retrieve it and try to create a new rpm.
> 
> Yes, it was fairly easy to create a new RPM from your SRPM.
> 
> Although, it appears you bump the source in tarball itself: spec file
> changelog shows on Sun May 10 you bumped the tarball to stable 3.3
> tree head (2b5681eba8; but you did not write the SHA1 in the
> changelog).  I mean: the SRPM source tarball named 3.3.3.tar.gz no
> longer matches the git tag V3_3_3 (rev-parse 678ac4c60f9).  This made
> it difficult to perform a diff/patch until I discovered your message
> in git log.
> 
> Perhaps I could suggest either:
> 
> 1/ Provide the SHA1 in the RPM spec file changelog ; or in the RPM
> source tarball as a file, e.g., "git rev-parse V3_3_STABLE >
> REVISION".)
> 
> 2/ Add a tag in git for RPM released versions, e.g., "V3_3_3-3".  This
> would make it easier to find/notice the tree used by the RPM, because
> I did review "git tag" output.
> 
> 3/ Keep the RPM source tarball as tree from V3_3_3 tag, then use
> patches against the stable branch (until V3_3_4, of course).  As I
> understand "conventional" RPM usage, this would be the approach.  I
> mean: the source tarball pgpool-II-3.3.3.tar.gz should remain V3_3_3.
> Then Source0, Source1, etc. are patches for 3.3.3-1, 3.3.3-2, .. until
> 3.3.4 (V3_3_4).  This is what I did: diff from 2b5681eba8 to
> V3_3_STABLE tip > 3_3_bump.patch, then use it as Source1 in spec file.

Thanks for greate suggestions and sorry for inconvenience due to my
mistakes. I think I should follow #3 way.

>>> I changed the spec file, where/how do I contribute patches in case you
>>> are interested?  (I do not see "contributing" guidelines on the wiki
>>> or in source docs.)
>>
>> Thanks for the idea. Looks great. Any suggestion what items should be
>> included in the guide?
> 
> Where and how to submit patches?  e.g., formatted patches to
> pgpool-hackers, or pgpool-general; or, open an issue and provide a
> patch; or, merge request [where?]

Submitting patches to pgpool-hackers list is preferred. Currently we
don't accept merge request in the way GitHub provides. However you
could clone the git tree to GitHub and propose patches using private
branches.

> Thank you for pgpool!
> 
> 
> Regards,
> Richard
> 
>>
>> Best regards,
>> --
>> Tatsuo Ishii
>> SRA OSS, Inc. Japan
>> English: http://www.sraoss.co.jp/index_en.php
>> Japanese:http://www.sraoss.co.jp
>>
>>> Regards,
>>> Richard
>>>
>>>
>>> On Wed, Jul 16, 2014 at 5:08 AM, Tatsuo Ishii <ishii at postgresql.org> wrote:
>>>> We have not decided the release schedule for 3.3.4 yet.
>>>>
>>>> At least there's one show stopper for 3.3.4:
>>>> http://www.pgpool.net/mantisbt/view.php?id=107
>>>>
>>>> There are some similar issues out there. Problem is, none of them
>>>> knows how to reproduce the problem.
>>>>
>>>> Best regards,
>>>> --
>>>> Tatsuo Ishii
>>>> SRA OSS, Inc. Japan
>>>> English: http://www.sraoss.co.jp/index_en.php
>>>> Japanese:http://www.sraoss.co.jp
>>>>
>>>>> Hello,
>>>>>
>>>>> Is there a release schedule?  Related, might there be a 3.3.4 release soon?
>>>>>
>>>>> Thank you for pgpool!
>>>>>
>>>>> Regards,
>>>>> Richard
>>>>> _______________________________________________
>>>>> pgpool-general mailing list
>>>>> pgpool-general at pgpool.net
>>>>> http://www.pgpool.net/mailman/listinfo/pgpool-general