Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20
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. +
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
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
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/
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
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/
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
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 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" and what
the ...s signify. It's not a big knowledge gap but I have other things
to worry about ...
regards, tom lane
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.
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.phpFrankly, 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
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.phpFrankly, 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
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=1000064and 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
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/