[pgpool-general: 3044] Re: Release schedule / next 3.3.x stable?
ishii at postgresql.org
Fri Jul 18 11:45:23 JST 2014
> 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 >
> 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
> Thank you for pgpool!
>> Best regards,
>> Tatsuo Ishii
>> SRA OSS, Inc. Japan
>> English: http://www.sraoss.co.jp/index_en.php
>>> 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:
>>>> 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
>>>>> Is there a release schedule? Related, might there be a 3.3.4 release soon?
>>>>> Thank you for pgpool!
>>>>> pgpool-general mailing list
>>>>> pgpool-general at pgpool.net
More information about the pgpool-general