Thread: pgsql: Stamp 9.1.8.

pgsql: Stamp 9.1.8.

From
Tom Lane
Date:
Stamp 9.1.8.

Branch
------
REL9_1_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/69c026512f1141a92dca118768d858e59d76a994

Modified Files
--------------
configure                        |   18 +++++++++---------
configure.in                     |    2 +-
doc/bug.template                 |    2 +-
src/include/pg_config.h.win32    |    8 ++++----
src/interfaces/libpq/libpq.rc.in |    8 ++++----
src/port/win32ver.rc             |    4 ++--
6 files changed, 21 insertions(+), 21 deletions(-)


Re: pgsql: Stamp 9.1.8.

From
Simon Riggs
Date:
On 4 February 2013 21:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Stamp 9.1.8.

Did you not get my mail about me being in the middle of backpatching?

I guess I can stop now.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


Re: pgsql: Stamp 9.1.8.

From
Tom Lane
Date:
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 4 February 2013 21:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Stamp 9.1.8.

> Did you not get my mail about me being in the middle of backpatching?

> I guess I can stop now.

4pm on the day of a release is way too late to be committing anything
(except security stuff ...).  If you felt you had a must-fix problem,
you should have been lobbying for a release postponement at least
six hours ago.

            regards, tom lane


Re: pgsql: Stamp 9.1.8.

From
Dave Page
Date:
On Mon, Feb 4, 2013 at 9:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> On 4 February 2013 21:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Stamp 9.1.8.
>
>> Did you not get my mail about me being in the middle of backpatching?
>
>> I guess I can stop now.
>
> 4pm on the day of a release is way too late to be committing anything
> (except security stuff ...).  If you felt you had a must-fix problem,
> you should have been lobbying for a release postponement at least
> six hours ago.

We should really freeze the code for 24 hours shouldn't we? That way
we know most, if not all of the buildfarm animals will have had a
chance to go red since the last code change.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Re: pgsql: Stamp 9.1.8.

From
Simon Riggs
Date:
On 4 February 2013 21:40, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> On 4 February 2013 21:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Stamp 9.1.8.
>
>> Did you not get my mail about me being in the middle of backpatching?
>
>> I guess I can stop now.
>
> 4pm on the day of a release is way too late to be committing anything
> (except security stuff ...).  If you felt you had a must-fix problem,
> you should have been lobbying for a release postponement at least
> six hours ago.

These timings might mean something to you, but I've never been aware
of such things because I'm not on the packagers list and its pure
silence everywhere else.

I've worked for much of the afternoon and evening on patches for this
because of the code changes, so thanks for that.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


Re: pgsql: Stamp 9.1.8.

From
Simon Riggs
Date:
On 4 February 2013 21:48, Dave Page <dpage@pgadmin.org> wrote:

> We should really freeze the code for 24 hours shouldn't we? That way
> we know most, if not all of the buildfarm animals will have had a
> chance to go red since the last code change.

Do whatever you like, as long as you tell me about it.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


Re: pgsql: Stamp 9.1.8.

From
Andrew Dunstan
Date:
On 02/04/2013 04:49 PM, Simon Riggs wrote:
> On 4 February 2013 21:40, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Simon Riggs <simon@2ndQuadrant.com> writes:
>>> On 4 February 2013 21:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> Stamp 9.1.8.
>>> Did you not get my mail about me being in the middle of backpatching?
>>> I guess I can stop now.
>> 4pm on the day of a release is way too late to be committing anything
>> (except security stuff ...).  If you felt you had a must-fix problem,
>> you should have been lobbying for a release postponement at least
>> six hours ago.
> These timings might mean something to you, but I've never been aware
> of such things because I'm not on the packagers list and its pure
> silence everywhere else.
>


I agree it can be hard to keep the dates in mind. Could we add a couple
of reminders for committers to the release procedures? Say 48 hours
before the release to say "the tree needs to go quiet in 24 hours" and
24 hours before to say "no commits without discussion until the release
is cut"?

cheers

andrew



Re: pgsql: Stamp 9.1.8.

From
Tom Lane
Date:
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 4 February 2013 21:48, Dave Page <dpage@pgadmin.org> wrote:
>> We should really freeze the code for 24 hours shouldn't we? That way
>> we know most, if not all of the buildfarm animals will have had a
>> chance to go red since the last code change.

> Do whatever you like, as long as you tell me about it.

No, the problem here is *you* didn't tell anybody what you were doing.
If it was something that would have merited a release postponement,
we could easily have done that.  But cramming unreviewed code into
a release at the last moment is a sure path to trouble.

As Dave says, one reason to avoid that is lack of buildfarm testing.
If you're pretty confident that a patch couldn't possibly have any
portability issues, then maybe a full buildfarm cycle isn't necessary;
but I think at least 6 or 8 hours is a good idea to give time for some
amount of sanity checking from the farm.

Another problem is that it takes time (and not a small amount of it) to
prepare the release notes.  I've been head-down on the release notes and
other details of the wrapping process since about six hours ago, and
would not have appreciated a last-minute commit that I needed to account
for in the notes.

We've never had, or particularly wanted, a formal policy about
pre-release code freezes.  But if you're going to start pushing the
boundaries of what's safe, maybe we will have to have one.

            regards, tom lane


Re: pgsql: Stamp 9.1.8.

From
Simon Riggs
Date:
On 4 February 2013 22:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> On 4 February 2013 21:48, Dave Page <dpage@pgadmin.org> wrote:
>>> We should really freeze the code for 24 hours shouldn't we? That way
>>> we know most, if not all of the buildfarm animals will have had a
>>> chance to go red since the last code change.
>
>> Do whatever you like, as long as you tell me about it.
>
> No, the problem here is *you* didn't tell anybody what you were doing.

Yes I did, I told hackers I was backpatching fixes and later I told
you. Did I follow your timing rules? No, because I've never heard of
them before and didn't know exact deadlines.

Not really clear why there's so much secrecy, but as long as there is,
don't expect me to follow the secret rules and don't dare accuse me of
pushing boundaries because I tried to fix a bug while your invisible
hour-glass ran out.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


Re: pgsql: Stamp 9.1.8.

From
Tom Lane
Date:
Andrew Dunstan <andrew@dunslane.net> writes:
> I agree it can be hard to keep the dates in mind. Could we add a couple
> of reminders for committers to the release procedures? Say 48 hours
> before the release to say "the tree needs to go quiet in 24 hours" and
> 24 hours before to say "no commits without discussion until the release
> is cut"?

Well, we already make an effort to notify people a couple of weeks out,
eg this time it was
http://www.postgresql.org/message-id/3973.1358911165@sss.pgh.pa.us
I'm not sure if additional notifications would be useful or just spam,
but we can try it if enough committers want it.

I'd really rather not institute a bureaucratic "freeze deadline" for our
releases.  I'd like to think it's obvious to everybody that code you're
still hacking on the evening of the wrap is Probably Not Ready.

What perhaps *could* use a little more process IMO is the release notes.
While we do put a fair amount of effort into the notes for major
releases, the process for minor-release notes has generally been that
either Bruce or I run around like mad on the release day to construct
release notes from the commit logs.  There have been gripes about the
results in several recent cycles, eg
http://www.postgresql.org/message-id/CAMkU=1zKWZypzQ5PEtnqr4TgNKD_ccYL4DyA33+O3R579e7Pxw@mail.gmail.com
so maybe we need to be drafting and reviewing these a bit further in
advance.

            regards, tom lane


Re: pgsql: Stamp 9.1.8.

From
Bruce Momjian
Date:
On Mon, Feb  4, 2013 at 11:14:51PM -0500, Tom Lane wrote:
> What perhaps *could* use a little more process IMO is the release notes.
> While we do put a fair amount of effort into the notes for major
> releases, the process for minor-release notes has generally been that
> either Bruce or I run around like mad on the release day to construct
> release notes from the commit logs.  There have been gripes about the

Tom is being kind.  Since I started traveling a few years ago, Tom has
created almost every minor release note document.  (I am in India now.)

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +


Re: pgsql: Stamp 9.1.8.

From
Simon Riggs
Date:
On 5 February 2013 04:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I'd really rather not institute a bureaucratic "freeze deadline" for our
> releases.

It would be helpful in the future if committers could be told when the
wrapping takes place, so we can self police.

> I'd like to think it's obvious to everybody that code you're
> still hacking on the evening of the wrap is Probably Not Ready.

It is, though in that case the difficulty was that patches for HEAD,
9.2 and 9.1 were all different and so a simple patch took many hours
of fiddling to get right.

Anyway, they aren't as critical as other patches and they'll get out
there one day...

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


Re: pgsql: Stamp 9.1.8.

From
Magnus Hagander
Date:
On Tue, Feb 5, 2013 at 9:42 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 5 February 2013 04:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> I'd really rather not institute a bureaucratic "freeze deadline" for our
>> releases.
>
> It would be helpful in the future if committers could be told when the
> wrapping takes place, so we can self police.

There was actually a discussion about this quite some time ago, and we
agreed on adding all committers (who were interested) to the packagers
list, just to get the information there.

Unfortunately, I forgot to actually *do* that as a result of the
discussion. My apologies for that. I'll go add you now - if there is
any other committer who has similar wishes, let me know and I will add
you there as well.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/