Thread: Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

From
Bruce Momjian
Date:
Preparations are being made for PostgreSQL releases 8.2.5, 8.1.10,
8.0.14, 7.4.18, 7.3.20.  The CVS branches are nearly ready.  The
releases will happen sometime early next week.  The packagers have been
contacted.

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

From
Alvaro Herrera
Date:
Bruce Momjian wrote:
> Preparations are being made for PostgreSQL releases 8.2.5, 8.1.10,
> 8.0.14, 7.4.18, 7.3.20.  The CVS branches are nearly ready.  The
> releases will happen sometime early next week.  The packagers have been
> contacted.

Does this mean that if I commit something in these days to those
branches, it will not show up in the releases?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


Re: Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

From
Bruce Momjian
Date:
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Preparations are being made for PostgreSQL releases 8.2.5, 8.1.10,
> > 8.0.14, 7.4.18, 7.3.20.  The CVS branches are nearly ready.  The
> > releases will happen sometime early next week.  The packagers have been
> > contacted.
> 
> Does this mean that if I commit something in these days to those
> branches, it will not show up in the releases?

It certainly will show up if you do it before the packagers pull their
CVS copies.  Right now configure/configure.in are not stamped so it is
impossible for a packager to use it.  I would check those files before
making changes to be sure.

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Bruce Momjian <bruce@momjian.us> writes:
> Alvaro Herrera wrote:
>> Does this mean that if I commit something in these days to those
>> branches, it will not show up in the releases?

> It certainly will show up if you do it before the packagers pull their
> CVS copies.

No, it will show up if you do it before Marc "cvs tag"s the release.
Which I am currently thinking shouldn't happen till Friday or so.

Please do be sure to get that CHECK_FOR_INTERRUPTS fix in there.
        regards, tom lane


Re: Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

From
Guillaume Lelarge
Date:
Tom Lane a écrit :
> Bruce Momjian <bruce@momjian.us> writes:
>> Alvaro Herrera wrote:
>>> Does this mean that if I commit something in these days to those
>>> branches, it will not show up in the releases?
> 
>> It certainly will show up if you do it before the packagers pull their
>> CVS copies.
> 
> No, it will show up if you do it before Marc "cvs tag"s the release.
> Which I am currently thinking shouldn't happen till Friday or so.
> 

Is it Marc's job to sync the translation on PostgreSQL CVS with those
from the pgtranslation project ? I remember this is a part of the build
process but I don't know who does this.

Thanks.

Regards.


-- 
Guillaume.
http://www.postgresqlfr.org/
http://dalibo.com/


Re: Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

From
Dave Page
Date:
Guillaume Lelarge wrote:
> Tom Lane a écrit :
>> Bruce Momjian <bruce@momjian.us> writes:
>>> Alvaro Herrera wrote:
>>>> Does this mean that if I commit something in these days to those
>>>> branches, it will not show up in the releases?
>>> It certainly will show up if you do it before the packagers pull their
>>> CVS copies.
>> No, it will show up if you do it before Marc "cvs tag"s the release.
>> Which I am currently thinking shouldn't happen till Friday or so.
>>
> 
> Is it Marc's job to sync the translation on PostgreSQL CVS with those
> from the pgtranslation project ? I remember this is a part of the build
> process but I don't know who does this.

No, thats Peter.

I'm not sure if he usually does it for point releases though.

Regards, Dave


Re: Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

From
Guillaume Lelarge
Date:
Dave Page a écrit :
> Guillaume Lelarge wrote:
>> Tom Lane a écrit :
>>> Bruce Momjian <bruce@momjian.us> writes:
>>>> Alvaro Herrera wrote:
>>>>> Does this mean that if I commit something in these days to those
>>>>> branches, it will not show up in the releases?
>>>> It certainly will show up if you do it before the packagers pull their
>>>> CVS copies.
>>> No, it will show up if you do it before Marc "cvs tag"s the release.
>>> Which I am currently thinking shouldn't happen till Friday or so.
>>>
>>
>> Is it Marc's job to sync the translation on PostgreSQL CVS with those
>> from the pgtranslation project ? I remember this is a part of the build
>> process but I don't know who does this.
> 
> No, thats Peter.
> 
> I'm not sure if he usually does it for point releases though.
> 

I hope he already did it for minor releases. If not, I wonder why
pgtranslation project has major branches.

I really need to see this happening at least on these minor releases. I
worked a lot on the .po files from 7.4, 8.0, 8.1 and 8.2, fixing some
translation's issues, "fine-tuning" the translations. Why isn't there
some kind of automatic process that sync the translations, once per
month for example ? if this can be done, I can work on this.


-- 
Guillaume.
http://www.postgresqlfr.org/
http://dalibo.com/


Re: Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

From
Simon Riggs
Date:
On Tue, 2007-09-11 at 18:56 -0400, Bruce Momjian wrote:

> Preparations are being made for PostgreSQL releases 8.2.5, 8.1.10,
> 8.0.14, 7.4.18, 7.3.20.  The CVS branches are nearly ready.  The
> releases will happen sometime early next week.  The packagers have been
> contacted.

The following bug fix has not yet been applied to CVS
http://archives.postgresql.org/pgsql-patches/2007-06/msg00100.php

It needs to be applied to CVS HEAD and REL8_2_STABLE. 

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



Dave Page <dpage@postgresql.org> writes:
> Guillaume Lelarge wrote:
>> Is it Marc's job to sync the translation on PostgreSQL CVS with those
>> from the pgtranslation project ? I remember this is a part of the build
>> process but I don't know who does this.

> No, thats Peter.

Peter usually does it --- in theory any committer could, but he actually
knows what to do and the rest of us would have to study ;-)

Peter, have you got time to sync the translation files before Friday?
        regards, tom lane


Re: Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

From
Dave Page
Date:
Tom Lane wrote:
> Dave Page <dpage@postgresql.org> writes:
>> Guillaume Lelarge wrote:
>>> Is it Marc's job to sync the translation on PostgreSQL CVS with those
>>> from the pgtranslation project ? I remember this is a part of the build
>>> process but I don't know who does this.
> 
>> No, thats Peter.
> 
> Peter usually does it --- in theory any committer could, but he actually
> knows what to do and the rest of us would have to study ;-)

Study or figure it out? If it hasn't already been it should be 
documented as part of the release process.

/D


Simon Riggs <simon@2ndquadrant.com> writes:
> The following bug fix has not yet been applied to CVS
> http://archives.postgresql.org/pgsql-patches/2007-06/msg00100.php

Frankly, this looks much more like it creates a bug than fixes one.
I have not looked at all of the original thread, but this adds a wart
(two warts, really) that seems certain to do the wrong thing in cases
other than the one you are thinking of.
        regards, tom lane


Dave Page <dpage@postgresql.org> writes:
> Tom Lane wrote:
>> Peter usually does it --- in theory any committer could, but he actually
>> knows what to do and the rest of us would have to study ;-)

> Study or figure it out? If it hasn't already been it should be 
> documented as part of the release process.

Well, RELEASE_CHANGES has

* Translation updatesTranslations are kept in the project "pgtranslation" on PgFoundry.1. Check out the messages module
(ofthe right branch).2. Check out the admin module.3. Run "sh .../admin/cp-po .../messages .../pgsql4. Commit.
 

but it's not real clear (to me) which is "the right branch" and what
the ...s signify.  It's not a big knowledge gap but I have other things
to worry about ...
        regards, tom lane


Re: Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

From
Guillaume Lelarge
Date:
Tom Lane a écrit :
> Dave Page <dpage@postgresql.org> writes:
>> Tom Lane wrote:
>>> Peter usually does it --- in theory any committer could, but he actually
>>> knows what to do and the rest of us would have to study ;-)
> 
>> Study or figure it out? If it hasn't already been it should be 
>> documented as part of the release process.
> 
> Well, RELEASE_CHANGES has
> 
> * Translation updates
>     Translations are kept in the project "pgtranslation" on PgFoundry.
>     1. Check out the messages module (of the right branch).
>     2. Check out the admin module.
>     3. Run "sh .../admin/cp-po .../messages .../pgsql
>     4. Commit.
> 
> but it's not real clear (to me) which is "the right branch"

They are named the same way PostgreSQL named its branches. For example
REL8_2 for PostgreSQL 8.2.

They are available here : http://pgfoundry.org/scm/?group_id=1000064

> and what the ...s signify.

.../admin/cp-po : ... is the path to the cp-po shell script you get when
you did step 2 ("Check out the admin module").

.../messages : ... is the path to the messages branch you get when you
did step 1 (Check out the messages module...)

.../pgsql : ... is the path to your source dir (same branch as messages)

> It's not a big knowledge gap but I have other things
> to worry about ...

It seems pretty straightforward now. Perhaps it can be used with cron.

Regards.


-- 
Guillaume.


Re: Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

From
Simon Riggs
Date:
On Wed, 2007-09-12 at 10:48 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > The following bug fix has not yet been applied to CVS
> > http://archives.postgresql.org/pgsql-patches/2007-06/msg00100.php
> 
> Frankly, this looks much more like it creates a bug than fixes one.
> I have not looked at all of the original thread, but this adds a wart
> (two warts, really) that seems certain to do the wrong thing in cases
> other than the one you are thinking of.

Well, that's not a great help for anybody.

What next action do you propose?

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



Re: Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

From
Simon Riggs
Date:
On Wed, 2007-09-12 at 10:48 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > The following bug fix has not yet been applied to CVS
> > http://archives.postgresql.org/pgsql-patches/2007-06/msg00100.php
> 
> Frankly, this looks much more like it creates a bug than fixes one.
> I have not looked at all of the original thread, but this adds a wart
> (two warts, really) that seems certain to do the wrong thing in cases
> other than the one you are thinking of.

Let me explain the bug and the fix briefly.

The current recovery code allows a file to be archived a second time,
which will fail if the archive_command is strict and refuses duplicate
files. The second failure occurs only in disaster mode, when we have no
partially written files from the failing server. The bug is fatal, but
there is an easy workaround, if you know it. The manual says this should
work and it does not.

I have added code that prevents a file from being archived when we know
for certain it has already been archived because we just de-archived it
during recovery. 

The fix also closes a loophole in XLogArchiveNotify by stopping the
writing of a .ready file if a .done already exists.

These actions fix the bug directly, following the main design.

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



Re: Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

From
Magnus Hagander
Date:
On Thu, Sep 13, 2007 at 12:12:28AM +0200, Guillaume Lelarge wrote:
> Tom Lane a écrit :
> > Dave Page <dpage@postgresql.org> writes:
> >> Tom Lane wrote:
> >>> Peter usually does it --- in theory any committer could, but he actually
> >>> knows what to do and the rest of us would have to study ;-)
> > 
> >> Study or figure it out? If it hasn't already been it should be 
> >> documented as part of the release process.
> > 
> > Well, RELEASE_CHANGES has
> > 
> > * Translation updates
> >     Translations are kept in the project "pgtranslation" on PgFoundry.
> >     1. Check out the messages module (of the right branch).
> >     2. Check out the admin module.
> >     3. Run "sh .../admin/cp-po .../messages .../pgsql
> >     4. Commit.
> > 
> > but it's not real clear (to me) which is "the right branch"
> 
> They are named the same way PostgreSQL named its branches. For example
> REL8_2 for PostgreSQL 8.2.
> 
> They are available here :
>   http://pgfoundry.org/scm/?group_id=1000064
> 
> > and what the ...s signify.
> 
> .../admin/cp-po : ... is the path to the cp-po shell script you get when
> you did step 2 ("Check out the admin module").
> 
> .../messages : ... is the path to the messages branch you get when you
> did step 1 (Check out the messages module...)
> 
> .../pgsql : ... is the path to your source dir (same branch as messages)
> 
> > It's not a big knowledge gap but I have other things
> > to worry about ...
> 
> It seems pretty straightforward now. Perhaps it can be used with cron.

No. Doing that with cron is a really bad idea, imho. We do *not* want any
automated commits going into the tree. If we wanted that, why did we bother
breaking it out in the first place, and not just give everybody commit
access, which would be the same thing?

That said, it seems easy enough. I'll be happy to help doing it, but I
don't want to step on the toes of someone already working on it. Peter -
let me know if you want help mergeing them for this release - I'm availabel
to help with that today or tomorrow.

//Magnus


Re: Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

From
Guillaume Lelarge
Date:
Magnus Hagander a écrit :
> On Thu, Sep 13, 2007 at 12:12:28AM +0200, Guillaume Lelarge wrote:
>> [...]
>> It seems pretty straightforward now. Perhaps it can be used with cron.
> 
> No. Doing that with cron is a really bad idea, imho. We do *not* want any
> automated commits going into the tree. If we wanted that, why did we bother
> breaking it out in the first place, and not just give everybody commit
> access, which would be the same thing?
> 

You're right. I haven't thought of that.

> That said, it seems easy enough. I'll be happy to help doing it, but I
> don't want to step on the toes of someone already working on it. Peter -
> let me know if you want help mergeing them for this release - I'm availabel
> to help with that today or tomorrow.
> 

Peter just sent a message on pgtranslation's mailing list, asking us
(translators) to put our updates in pgtranslation's CVS ASAP. He'll
synchronize the translations tonight.

Thanks anyway.

Regards.


-- 
Guillaume.
http://www.postgresqlfr.org/
http://dalibo.com/