Re: [HACKERS] Release notes introductory text

2007-10-18 Thread Kevin Grittner
 On Thu, Oct 18, 2007 at 12:34 AM, in message
[EMAIL PROTECTED], Bruce Momjian [EMAIL PROTECTED] wrote:

 This release represents a major leap forward for PostgreSQL by adding
 significant new functionality and performance enhancements. This was
 made possible by a growing community that has dramatically accelerated
 the pace of development. This release adds the follow major
 capabilities:
 
If we want to have a short intro to promote the new release,
this sounds good to me.
 
-Kevin
 



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] Release notes introductory text

2007-10-17 Thread Bruce Momjian
D'Arcy J.M. Cain wrote:
 On Thu, 11 Oct 2007 16:34:14 -0400 (EDT)
 Bruce Momjian [EMAIL PROTECTED] wrote:
  Kevin Grittner wrote:
productnamePostgreSQL/. Many complex ideas that normally take years
to implement were added rapidly to this release by our development team.

   You do realize that this will make many managers very reluctant to adopt
   it before it has settled in for many months, right?

   If the goal is to provide fair warning of a high-than-usual-risk
   release, you've got it covered.
  
  No, that was not the intent. The indent was to say we got a lot done in
  one year.  You have a suggestion?
 
 What if you changed were added rapidly to were quickly brought to
 maturity or something like that?

Updated text is:

This release represents a major leap forward for PostgreSQL by adding
significant new functionality and performance enhancements. This was
made possible by a growing community that has dramatically accelerated
the pace of development. This release adds the follow major
capabilities:

-- 
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] Release notes introductory text

2007-10-16 Thread rm_rs

Kevin Grittner wrote:

How exactly do you expect the software to get from a .0 to a .1 release,
or to have addressed the bugs that might bite you when it does get to .1,
if you aren't helping to test it?
  

In most environments I've seen, developer and QA systems don't hesitate
to move to .0 releases (or even beta).   I agree with Joshua that it's
nerve wracking to move _production_ systems to .0 releases from most
software vendors.

 
My philosophy is that the final QA environment should be as close to

the production environment as can be arranged, but that difference in
the development and initial test environments contribute to
robustness.
  

Sorry if I implied otherwise - I was assuming an environment
where QA has multiple environments; one of which clearly
should be the same as production.


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [HACKERS] Release notes introductory text

2007-10-15 Thread Kevin Grittner
 On Fri, Oct 12, 2007 at 12:37 PM, in message
[EMAIL PROTECTED], Ron Mayer
[EMAIL PROTECTED] wrote: 
 Tom Lane wrote:
 Joshua D. Drake [EMAIL PROTECTED] writes:
 With respect to you Kevin, your managers should wait. You don't
 install .0 releases of any software into production without months
 of testing. At which point, normally a .1 release has come out anyway.
 
All generalities are false.
 
Everyone needs to assess the risks and benefits for their own
environment, and figure out how close the can comfortably be to the
bleeding edge on any new technology.
 
We have been able to exercise not only .0 but RC and beta releases in
production because we have central servers holding consolidated
copies of the various distributed originals; with multiple copies of
these databases.  So we have redundancy in two dimensions, not to
mention backups of the redundant databases and two parallel backup
strategies for the original data.  And we synchronize the originals
to the copies during any slack time, and investigate any
discrepancies.  If the release seems stable enough, we'll put one copy
of the live redundant system at risk on beta or RC.
 
Is this testing or production?  I guess you could argue the semantics
either way.  Of course we do some load tests by replaying the
production HTTP request stream through test renderers; but it's being
fed 24/7 from a production environment, and we've been known to use
it for ad hoc queries.  I think we've even load-shifted the web site
over to it briefly to perform maintenance on the other servers.
 
 How exactly do you expect the software to get from a .0 to a .1 release,
 or to have addressed the bugs that might bite you when it does get to .1,
 if you aren't helping to test it?
 
 In most environments I've seen, developer and QA systems don't hesitate
 to move to .0 releases (or even beta).   I agree with Joshua that it's
 nerve wracking to move _production_ systems to .0 releases from most
 software vendors.
 
My philosophy is that the final QA environment should be as close to
the production environment as can be arranged, but that difference in
the development and initial test environments contribute to
robustness.
 
-Kevin
 


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] Release notes introductory text

2007-10-12 Thread Simon Riggs
On Thu, 2007-10-11 at 17:46 -0400, Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  Kevin Grittner wrote:
  If the goal is to provide fair warning of a high-than-usual-risk
  release, you've got it covered.
 
  No, that was not the intent. The indent was to say we got a lot done in
  one year.  You have a suggestion?
 
 Yeah: take the entire paragraph out again.  I concur with Neil that
 it's nothing but marketing fluff, and inaccurate fluff at that.

I think it is important that we are up beat about what we have achieved,
but perhaps we should avoid opinions in the release notes.

Perhaps it should be part of the press release?

We should say that the release notes get discussed on -hackers and the
press releases get discussed on -advocacy. That way the scope is clear
and we can keep the marketing at arms length from the engineering. I
think we need both, but in appropriate places.

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


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] Release notes introductory text

2007-10-12 Thread Magnus Hagander
On Fri, Oct 12, 2007 at 07:51:13AM +0100, Simon Riggs wrote:
 On Thu, 2007-10-11 at 17:46 -0400, Tom Lane wrote:
  Bruce Momjian [EMAIL PROTECTED] writes:
   Kevin Grittner wrote:
   If the goal is to provide fair warning of a high-than-usual-risk
   release, you've got it covered.
  
   No, that was not the intent. The indent was to say we got a lot done in
   one year.  You have a suggestion?
  
  Yeah: take the entire paragraph out again.  I concur with Neil that
  it's nothing but marketing fluff, and inaccurate fluff at that.
 
 I think it is important that we are up beat about what we have achieved,
 but perhaps we should avoid opinions in the release notes.
 
 Perhaps it should be part of the press release?

It certainly sounds a lot more like press release than release notes to me...

//Magnus

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] Release notes introductory text

2007-10-12 Thread Ron Mayer
Tom Lane wrote:
 Joshua D. Drake [EMAIL PROTECTED] writes:
 With respect to you Kevin, your managers should wait. You don't
 install .0 releases of any software into production without months
 of testing. At which point, normally a .1 release has come out anyway.
 
 How exactly do you expect the software to get from a .0 to a .1 release,
 or to have addressed the bugs that might bite you when it does get to .1,
 if you aren't helping to test it?

In most environments I've seen, developer and QA systems don't hesitate
to move to .0 releases (or even beta).   I agree with Joshua that it's
nerve wracking to move _production_ systems to .0 releases from most
software vendors.

 Now I realize that you did say test above, but way too often I see
 this sort of argument as a justification for doing nothing and expecting
 somebody else to fix it.

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] Release notes introductory text

2007-10-11 Thread Kevin Grittner
 On Thu, Oct 11, 2007 at  3:04 PM, in message
[EMAIL PROTECTED], Bruce Momjian [EMAIL PROTECTED] wrote:
 
 This release represents a major leap forward by adding significant new
 functionality and performance enhancements to
 productnamePostgreSQL/. Many complex ideas that normally take years
 to implement were added rapidly to this release by our development team.
 
You do realize that this will make many managers very reluctant to adopt
it before it has settled in for many months, right?
 
If the goal is to provide fair warning of a high-than-usual-risk
release, you've got it covered.
 
-Kevin
 



---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [HACKERS] Release notes introductory text

2007-10-11 Thread Bruce Momjian
Kevin Grittner wrote:
  On Thu, Oct 11, 2007 at  3:04 PM, in message
 [EMAIL PROTECTED], Bruce Momjian [EMAIL PROTECTED] wrote:
  
  This release represents a major leap forward by adding significant new
  functionality and performance enhancements to
  productnamePostgreSQL/. Many complex ideas that normally take years
  to implement were added rapidly to this release by our development team.
  
 You do realize that this will make many managers very reluctant to adopt
 it before it has settled in for many months, right?
  
 If the goal is to provide fair warning of a high-than-usual-risk
 release, you've got it covered.

No, that was not the intent. The indent was to say we got a lot done in
one year.  You have a suggestion?

-- 
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Release notes introductory text

2007-10-11 Thread D'Arcy J.M. Cain
On Thu, 11 Oct 2007 16:34:14 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
 Kevin Grittner wrote:
   productnamePostgreSQL/. Many complex ideas that normally take years
   to implement were added rapidly to this release by our development team.
   
  You do realize that this will make many managers very reluctant to adopt
  it before it has settled in for many months, right?
   
  If the goal is to provide fair warning of a high-than-usual-risk
  release, you've got it covered.
 
 No, that was not the intent. The indent was to say we got a lot done in
 one year.  You have a suggestion?

What if you changed were added rapidly to were quickly brought to
maturity or something like that?

-- 
D'Arcy J.M. Cain [EMAIL PROTECTED] |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Release notes introductory text

2007-10-11 Thread Neil Conway
On Thu, 2007-10-11 at 16:04 -0400, Bruce Momjian wrote:
 I have added the following introductory paragraph to the release notes:
 
   This release represents a major leap forward by adding significant new
   functionality and performance enhancements to
   productnamePostgreSQL/. Many complex ideas that normally take years
   to implement were added rapidly to this release by our development team.
   This release starts productnamePostgreSQL/ on a trajectory moving
   beyond feature-parity with other database systems to a time when
   productnamePostgreSQL/ will be a technology leader in the database
   field.

Frankly, this sounds like empty hyperbole to me. There is a LOT of work
left to do before we reach feature parity with the major players, let
alone become a technology leader in the database field. I would
personally vote for just saying that this release brings with it a lot
of useful new features and performance improvements, and leave it up to
the reader to decide whether we're on a trajectory moving beyond
feature-parity.

If you want to compare where we are with the major players, I think it
would be more accurate to say that we're doing fairly well on OLTP
oriented features, but there is a lot of work left on OLAP
functionality.

-Neil



---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] Release notes introductory text

2007-10-11 Thread Andrew Hammond
On 10/11/07, Bruce Momjian [EMAIL PROTECTED] wrote:

 Kevin Grittner wrote:
   On Thu, Oct 11, 2007 at  3:04 PM, in message
  [EMAIL PROTECTED], Bruce Momjian [EMAIL PROTECTED]
 wrote:
 
   This release represents a major leap forward by adding significant new
   functionality and performance enhancements to
   productnamePostgreSQL/. Many complex ideas that normally take
 years
   to implement were added rapidly to this release by our development
 team.
 
  You do realize that this will make many managers very reluctant to adopt
  it before it has settled in for many months, right?
 
  If the goal is to provide fair warning of a high-than-usual-risk
  release, you've got it covered.

 No, that was not the intent. The indent was to say we got a lot done in
 one year.  You have a suggestion?


Well, a number of these were bumped from 8.2, so it might be a good idea to
go with something like complex improvements long under development have
come to fruition. For the reason suggested above, I don't think it's a
great idea to try to emphasize the impressive speed with which some of these
features have actually been implemented. I don't know that there's any
credible way to tell people that although these things were done quickly
they were also done with the exceptional care and attention to detail for
which the PostgreSQL development community is famous.

I really like your wording about how we're going beyond feature parity.
That's exactly the kind of stance for which the World's Most Advanced Open
Source Database ought to be aiming. As long as we can avoid the negative
connotations associated with experimental.

Andrew


Re: [HACKERS] Release notes introductory text

2007-10-11 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 Kevin Grittner wrote:
 If the goal is to provide fair warning of a high-than-usual-risk
 release, you've got it covered.

 No, that was not the intent. The indent was to say we got a lot done in
 one year.  You have a suggestion?

Yeah: take the entire paragraph out again.  I concur with Neil that
it's nothing but marketing fluff, and inaccurate fluff at that.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Release notes introductory text

2007-10-11 Thread Kevin Grittner
 On Thu, Oct 11, 2007 at  3:34 PM, in message
[EMAIL PROTECTED], Bruce Momjian [EMAIL PROTECTED] wrote:

 The indent was to say we got a lot done in
 one year.  You have a suggestion?
 
My suggestion would be to stay away from statements about the speed
of development and focus on the user benefits of the release.
 
Before my previous post I asked a manager to read the statement and
let me know what he thought, and he said that it sounds great if it
works but that it sounded like something was being rushed into
production, which in his experience always meant a lot of bugs.  I
think everyone who contributed to these major improvements deserves
to be proud of their productivity, but it's hard to talk about that
in public without generating the wrong impression.
 
Come to think of it, a statements about high productivity, valuable
contributions, and community effort all spin OK.  I would stay away
from heroic effort, though, as it is used in a negative way in
some agile programming documents.
 
Again, above all, focus on answering the question:
 
What benefit do I get from moving to this release?
 
-Kevin
 



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] Release notes introductory text

2007-10-11 Thread Joshua D. Drake
On Thu, 11 Oct 2007 15:26:43 -0500
Kevin Grittner [EMAIL PROTECTED] wrote:

  This release represents a major leap forward by adding significant
  new functionality and performance enhancements to
  productnamePostgreSQL/. Many complex ideas that normally take
  years to implement were added rapidly to this release by our
  development team.
  
 You do realize that this will make many managers very reluctant to
 adopt it before it has settled in for many months, right?

With respect to you Kevin, your managers should wait. You don't
install .0 releases of any software into production without months
of testing. At which point, normally a .1 release has come out anyway.

Sincerely,

Joshua D. Drake


  
 If the goal is to provide fair warning of a high-than-usual-risk
 release, you've got it covered.
  
 -Kevin
  
 
 
 
 ---(end of
 broadcast)--- TIP 7: You can help support the
 PostgreSQL project by donating at
 
 http://www.postgresql.org/about/donate
 


-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564   24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997  http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/



signature.asc
Description: PGP signature


Re: [HACKERS] Release notes introductory text

2007-10-11 Thread Michael Glaesemann


On Oct 11, 2007, at 18:51 , Joshua D. Drake wrote:


With respect to you Kevin, your managers should wait. You don't
install .0 releases of any software into production without months
of testing. At which point, normally a .1 release has come out anyway.


At the same time, an open source project such as PostgreSQL provides  
advantages here, in that preliminary testing can be performed during  
the development of the release, verified, of course, after the  
release has been made.


Michael Glaesemann
grzm seespotcode net




PGP.sig
Description: This is a digitally signed message part


Re: [HACKERS] Release notes introductory text

2007-10-11 Thread Tom Lane
Joshua D. Drake [EMAIL PROTECTED] writes:
 With respect to you Kevin, your managers should wait. You don't
 install .0 releases of any software into production without months
 of testing. At which point, normally a .1 release has come out anyway.

How exactly do you expect the software to get from a .0 to a .1 release,
or to have addressed the bugs that might bite you when it does get to .1,
if you aren't helping to test it?

Now I realize that you did say test above, but way too often I see
this sort of argument as a justification for doing nothing and expecting
somebody else to fix it.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] Release notes introductory text

2007-10-11 Thread Joshua D. Drake
On Thu, 11 Oct 2007 21:31:20 -0400
Tom Lane [EMAIL PROTECTED] wrote:

 Joshua D. Drake [EMAIL PROTECTED] writes:
  With respect to you Kevin, your managers should wait. You don't

 
 Now I realize that you did say test above, but way too often I see
 this sort of argument as a justification for doing nothing and
 expecting somebody else to fix it.

Tom, I get paid to deal with it, remember? I hardly want to do nothing
and expect someone else to fix it. I wouldn't get paid :) I just believe
that the sanest course of action with my customers data, is the
conservative course of action.

That means, testing, before, during and after release. It also means
unless there is something extremely pertinent (I have several customers
threatening to fly out and strangle me personally if I don't upgrade
them to 8.3 ASAP because of HOT), I won't upgrade them until I have
confidence in production deployment.

There are varying degrees of need. Some will need 8.3 as soon as
possible, but even those I would professionally suggest they put
against a test harness of production data. Otherwise they are looking
for trouble and they are may or may not find it.

When one has been doing this as long as I have, with as many postgresql
deployments as I have... you get gun shy and only upgrade when you
must. That means dot releases, or specific business value.

I have many, many customers that will be on 8.1 for a very, very long
time to come. I will concede that it is a very hard argument for
*anyone* to be running less than 8.1.

Sincerely,

Joshua D. Drake


 
   regards, tom lane
 
 ---(end of
 broadcast)--- TIP 4: Have you searched our
 list archives?
 
http://archives.postgresql.org
 


-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564   24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997  http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/



signature.asc
Description: PGP signature