Thread: pgsql: Stamp 9.1.8.
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(-)
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
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
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
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
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
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
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
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
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
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. +
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
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/