Thread: Release notes introductory text
[ BCC to docs and hackers. Sorry this seems like the only logical way
to do this.]
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
<productname>PostgreSQL</>. Many complex ideas that normally take years
to implement were added rapidly to this release by our development team.
This release starts <productname>PostgreSQL</> on a trajectory moving
beyond feature-parity with other database systems to a time when
<productname>PostgreSQL</> will be a technology leader in the database
field. Major new capabilities in this release include:
The full release text with my edits to "major" and "migration" sections
is included:
http://momjian.us/main/writings/pgsql/sgml/release-8-3.html
Comments?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
>>> On Thu, Oct 11, 2007 at 3:04 PM, in message <200710112004.l9BK4eq03596@momjian.us>, Bruce Momjian <bruce@momjian.us> wrote: > This release represents a major leap forward by adding significant new > functionality and performance enhancements to > <productname>PostgreSQL</>. 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
Kevin Grittner wrote: > >>> On Thu, Oct 11, 2007 at 3:04 PM, in message > <200710112004.l9BK4eq03596@momjian.us>, Bruce Momjian <bruce@momjian.us> wrote: > > > This release represents a major leap forward by adding significant new > > functionality and performance enhancements to > > <productname>PostgreSQL</>. 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Thu, 11 Oct 2007 16:34:14 -0400 (EDT) Bruce Momjian <bruce@momjian.us> wrote: > Kevin Grittner wrote: > > > <productname>PostgreSQL</>. 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 <darcy@druid.net> | 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.
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 > <productname>PostgreSQL</>. Many complex ideas that normally take years > to implement were added rapidly to this release by our development team. > This release starts <productname>PostgreSQL</> on a trajectory moving > beyond feature-parity with other database systems to a time when > <productname>PostgreSQL</> 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
On 10/11/07, Bruce Momjian <bruce@momjian.us> wrote:
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
Kevin Grittner wrote:
> >>> On Thu, Oct 11, 2007 at 3:04 PM, in message
> <200710112004.l9BK4eq03596@momjian.us>, Bruce Momjian < bruce@momjian.us> wrote:
>
> > This release represents a major leap forward by adding significant new
> > functionality and performance enhancements to
> > <productname>PostgreSQL</>. 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
Bruce Momjian <bruce@momjian.us> 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
>>> On Thu, Oct 11, 2007 at 3:34 PM, in message <200710112034.l9BKYEA26708@momjian.us>, Bruce Momjian <bruce@momjian.us> 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
On Thu, 11 Oct 2007 15:26:43 -0500 "Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote: > > This release represents a major leap forward by adding significant > > new functionality and performance enhancements to > > <productname>PostgreSQL</>. 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/
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
"Joshua D. Drake" <jd@commandprompt.com> 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
On Thu, 11 Oct 2007 21:31:20 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Joshua D. Drake" <jd@commandprompt.com> 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/
On Thu, 2007-10-11 at 17:46 -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> 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
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 <bruce@momjian.us> 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
Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> 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.
>>> On Fri, Oct 12, 2007 at 12:37 PM, in message <470FB0DD.2080104@cheapcomplexdevices.com>, Ron Mayer <rm_pg@cheapcomplexdevices.com> wrote: > Tom Lane wrote: >> "Joshua D. Drake" <jd@commandprompt.com> 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
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.
D'Arcy J.M. Cain wrote: > On Thu, 11 Oct 2007 16:34:14 -0400 (EDT) > Bruce Momjian <bruce@momjian.us> wrote: > > Kevin Grittner wrote: > > > > <productname>PostgreSQL</>. 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 addingsignificant new functionality and performance enhancements.This wasmade possible by a growing community that has dramatically acceleratedthe pace of development. Thisrelease adds the follow majorcapabilities: -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
>>> On Thu, Oct 18, 2007 at 12:34 AM, in message <200710180534.l9I5Y9V22110@momjian.us>, Bruce Momjian <bruce@momjian.us> 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