Release notes
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.
Will that be in a few years, or are you traveling backwards in time? ;-)
cheers
andrew
Andrew Dunstan wrote:
Bruce Momjian wrote:
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.Will that be in a few years, or are you traveling backwards in time? ;-)
Sorry, September 18. I will probably be done before then, but it seems
best to set a date I know I will hit.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On Tue, Sep 12, 2006 at 02:31:22PM -0400, Bruce Momjian wrote:
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.
The next Monday, August 18, is in 2008. Surely that'll be
enough time ;-)
--
Michael Fuhr
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Michael Fuhr
Sent: 12 September 2006 19:57
To: Bruce Momjian
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Release notesOn Tue, Sep 12, 2006 at 02:31:22PM -0400, Bruce Momjian wrote:
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.The next Monday, August 18, is in 2008. Surely that'll be
enough time ;-)
Someone will have to speak to Denis about getting Bruce more community
time :-)
Regards, Dave.
Dave Page wrote:
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Michael Fuhr
Sent: 12 September 2006 19:57
To: Bruce Momjian
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Release notesOn Tue, Sep 12, 2006 at 02:31:22PM -0400, Bruce Momjian wrote:
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.The next Monday, August 18, is in 2008. Surely that'll be
enough time ;-)Someone will have to speak to Denis about getting Bruce more community
time :-)
It is more family activity that is causing my delays. I was hoping to
carve out last weekend to work on it, but I couldn't. I wish I could
blame Denis. ;-)
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
Dave Page wrote:
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Michael Fuhr
Sent: 12 September 2006 19:57
To: Bruce Momjian
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Release notesOn Tue, Sep 12, 2006 at 02:31:22PM -0400, Bruce Momjian wrote:
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.The next Monday, August 18, is in 2008. Surely that'll be
enough time ;-)Someone will have to speak to Denis about getting Bruce more community
time :-)It is more family activity that is causing my delays. I was hoping to
carve out last weekend to work on it, but I couldn't. I wish I could
blame Denis. ;-)
Bah!! who needs family ;)
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Bruce Momjian wrote:
Dave Page wrote:
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Michael Fuhr
Sent: 12 September 2006 19:57
To: Bruce Momjian
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Release notesOn Tue, Sep 12, 2006 at 02:31:22PM -0400, Bruce Momjian wrote:
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.The next Monday, August 18, is in 2008. Surely that'll be
enough time ;-)Someone will have to speak to Denis about getting Bruce more community
time :-)It is more family activity that is causing my delays. I was hoping to
carve out last weekend to work on it, but I couldn't. I wish I could
blame Denis. ;-)
The family is more important than PostgreSQL. Having fun with the
family indeed gives energy to someone to work. So, go family fun!
Best Regards,
Carlo Florendo
Astra Philippines Inc.
www.astra.ph
On Tuesday 12 September 2006 14:49, Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.Will that be in a few years, or are you traveling backwards in time? ;-)
Sorry, September 18. I will probably be done before then, but it seems
best to set a date I know I will hit.
Here we go again with another developer who keeps making endless promises for
vaporware patches that never show up. We've already set on-disk bit-map
indexes straight on this and I think giving you special treatment sets a bad
tone for the project. At this point I think we have to cut the release notes
from this release... maybe they can be added back in for 8.3.
;^)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
After takin a swig o' Arrakan spice grog, xzilla@users.sourceforge.net (Robert Treat) belched out:
On Tuesday 12 September 2006 14:49, Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.Will that be in a few years, or are you traveling backwards in time? ;-)
Sorry, September 18. I will probably be done before then, but it seems
best to set a date I know I will hit.Here we go again with another developer who keeps making endless promises for
vaporware patches that never show up. We've already set on-disk bit-map
indexes straight on this and I think giving you special treatment sets a bad
tone for the project. At this point I think we have to cut the release notes
from this release... maybe they can be added back in for 8.3.;^)
I'm happy they're available; I'm prepping a talk on "new stuff" for
Ohio LinuxFest, and for the notes to be available now is pretty ideal.
Seems to me that what I mostly do is print off a copy, show how thick
it is, and say "There are a really a lot of things improved, as
visible on this list; alas, few are obviously 'sexy' new things..."
In seriousness, that is somewhat troublesome with this release, and
that's a challenge for the press release. (Work on that can
presumably proceed, now, in that there is a feature list to try to
distill.)
There are lots of little things that I like; it's just hard to point
to any big, easily identifiable things, like PITR, 2PC, recursive
queries, and such.
--
output = ("cbbrowne" "@" "gmail.com")
http://linuxdatabases.info/info/lsf.html
"Well, I wish you'd just tell me rather than trying to engage my
enthusiasm, because I haven't got one." -- Marvin the Paranoid Android
Robert Treat wrote:
On Tuesday 12 September 2006 14:49, Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.Will that be in a few years, or are you traveling backwards in time? ;-)
Sorry, September 18. I will probably be done before then, but it seems
best to set a date I know I will hit.Here we go again with another developer who keeps making endless promises for
vaporware patches that never show up. We've already set on-disk bit-map
indexes straight on this and I think giving you special treatment sets a bad
tone for the project. At this point I think we have to cut the release notes
from this release... maybe they can be added back in for 8.3.
Very good one!
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
Robert Treat wrote:
On Tuesday 12 September 2006 14:49, Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.Will that be in a few years, or are you traveling backwards in time? ;-)
Sorry, September 18. I will probably be done before then, but it seems
best to set a date I know I will hit.Here we go again with another developer who keeps making endless promises for
vaporware patches that never show up. We've already set on-disk bit-map
indexes straight on this and I think giving you special treatment sets a bad
tone for the project. At this point I think we have to cut the release notes
from this release... maybe they can be added back in for 8.3.Very good one!
Yeah, it was funny, but it points a problem which is that we are
overloading you to do the release notes thing. I agree that we should
push individual developers to include release notes updates on the
patches they submit. They are easier to write than the documentation
update in any case (which as you say, not everyone submits), mainly
because they are way shorter.
(Or maybe not _push_ them to do that, but at least not forbid updating
the release notes which AFAIK is the current policy.)
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Christopher Browne wrote:
Seems to me that what I mostly do is print off a copy, show how thick
it is, and say "There are a really a lot of things improved, as
visible on this list; alas, few are obviously 'sexy' new things..."
Think "marshmallow explosion". Lots of white, fluffy stuff everywhere.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Alvaro Herrera wrote:
Bruce Momjian wrote:
Robert Treat wrote:
On Tuesday 12 September 2006 14:49, Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.Will that be in a few years, or are you traveling backwards in time? ;-)
Sorry, September 18. I will probably be done before then, but it seems
best to set a date I know I will hit.Here we go again with another developer who keeps making endless promises for
vaporware patches that never show up. We've already set on-disk bit-map
indexes straight on this and I think giving you special treatment sets a bad
tone for the project. At this point I think we have to cut the release notes
from this release... maybe they can be added back in for 8.3.Very good one!
Yeah, it was funny, but it points a problem which is that we are
overloading you to do the release notes thing. I agree that we should
push individual developers to include release notes updates on the
patches they submit. They are easier to write than the documentation
update in any case (which as you say, not everyone submits), mainly
because they are way shorter.(Or maybe not _push_ them to do that, but at least not forbid updating
the release notes which AFAIK is the current policy.)
There are problems with this. First, since everyone isn't going to do
it, I still have to go through all the CVS logs, and then I have to
merge the created list to avoid duplicates. Then there is the problem
that we need consistent wording through the release notes, so again, I
have to wack around some more text. Doing it in one pass is the most
reliable, and efficient.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
There are problems with this.
There are going to be problems with just about any proposal, but I think
updating the release notes incrementally is still a clear net win.
First, since everyone isn't going to do it, I still have to go
through all the CVS logs, and then I have to merge the created list
to avoid duplicates.
A solution would be to require all the committers to do it: we can say
that any CVS commit that makes a user-visible change should update the
release notes as part of the commit. If anyone sees a commit that fails
to do this, they can flame^H email the guilty party. People submitting
patches can include an update to the release notes directly, or else the
committer can write the release note entry if necessary. This is similar
to the policy on documentation updates, which seems to have worked
decently well.
I would be happy to volunteer to do my best to ensure that this policy
is applied for the 8.3 development cycle, if enough people agree that
this is worth doing.
Then there is the problem that we need consistent wording through the
release notes, so again, I have to wack around some more text.
I think this is a strange objection. Many different people have
contributed to the documentation, and yet we've managed to keep the
wording reasonably consistent throughout -- I think we can manage
consistent usage in some release notes. Frankly, the grammar and diction
in the release notes is often not perfect on the first draft anyway, so
there needs to be copy-editing done regardless.
Doing it in one pass is the most reliable, and efficient.
Does anyone else have any opinions on this?
-Neil
The only win to doing this incrementally is that people will have some
idea of what is the release before I create the list just before beta.
This will probably save me only minimal amount of time compared to the
extra work it will require of everyone. Also consider patches on top of
patches are going to require someone knowing what is already on the list.
---------------------------------------------------------------------------
Neil Conway wrote:
Bruce Momjian wrote:
There are problems with this.
There are going to be problems with just about any proposal, but I think
updating the release notes incrementally is still a clear net win.First, since everyone isn't going to do it, I still have to go
through all the CVS logs, and then I have to merge the created list
to avoid duplicates.A solution would be to require all the committers to do it: we can say
that any CVS commit that makes a user-visible change should update the
release notes as part of the commit. If anyone sees a commit that fails
to do this, they can flame^H email the guilty party. People submitting
patches can include an update to the release notes directly, or else the
committer can write the release note entry if necessary. This is similar
to the policy on documentation updates, which seems to have worked
decently well.I would be happy to volunteer to do my best to ensure that this policy
is applied for the 8.3 development cycle, if enough people agree that
this is worth doing.Then there is the problem that we need consistent wording through the
release notes, so again, I have to wack around some more text.I think this is a strange objection. Many different people have
contributed to the documentation, and yet we've managed to keep the
wording reasonably consistent throughout -- I think we can manage
consistent usage in some release notes. Frankly, the grammar and diction
in the release notes is often not perfect on the first draft anyway, so
there needs to be copy-editing done regardless.Doing it in one pass is the most reliable, and efficient.
Does anyone else have any opinions on this?
-Neil
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Also, personally, I would rather do it all at once rather than
throughout the development cycle. It is like moving 100 potatoes one at
a time compared to placing them in a sack and moving them all at once.
Also, we are having trouble getting enough people to review/commit.
Does adding an extra step discourage them even further? I asked for
backpatch mentions in the CVS commit logs and got pushback from that.
How is maintaining another file on every commit going to go over?
I have enough trouble keeping CVS activity straight. This would add an
additional item for me to keep in sync with CVS.
---------------------------------------------------------------------------
Bruce Momjian wrote:
The only win to doing this incrementally is that people will have some
idea of what is the release before I create the list just before beta.
This will probably save me only minimal amount of time compared to the
extra work it will require of everyone. Also consider patches on top of
patches are going to require someone knowing what is already on the list.---------------------------------------------------------------------------
Neil Conway wrote:
Bruce Momjian wrote:
There are problems with this.
There are going to be problems with just about any proposal, but I think
updating the release notes incrementally is still a clear net win.First, since everyone isn't going to do it, I still have to go
through all the CVS logs, and then I have to merge the created list
to avoid duplicates.A solution would be to require all the committers to do it: we can say
that any CVS commit that makes a user-visible change should update the
release notes as part of the commit. If anyone sees a commit that fails
to do this, they can flame^H email the guilty party. People submitting
patches can include an update to the release notes directly, or else the
committer can write the release note entry if necessary. This is similar
to the policy on documentation updates, which seems to have worked
decently well.I would be happy to volunteer to do my best to ensure that this policy
is applied for the 8.3 development cycle, if enough people agree that
this is worth doing.Then there is the problem that we need consistent wording through the
release notes, so again, I have to wack around some more text.I think this is a strange objection. Many different people have
contributed to the documentation, and yet we've managed to keep the
wording reasonably consistent throughout -- I think we can manage
consistent usage in some release notes. Frankly, the grammar and diction
in the release notes is often not perfect on the first draft anyway, so
there needs to be copy-editing done regardless.Doing it in one pass is the most reliable, and efficient.
Does anyone else have any opinions on this?
-Neil
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
--
Bruce Momjian bruce@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:
How is maintaining another file on every commit going to go over?
If memory serves, we tried this before --- back in the 7.4 devel cycle,
people were supposed to add small entries to release.sgml every time
they committed something worth mentioning in the release notes. This
was not done anywhere near consistently enough to be useful, however,
and so we gave it up. ISTR that we had patch-merging problems too,
because any patch submitters who took it seriously were trying to patch
the same chunk of release.sgml.
I tend to agree with Bruce that it's more efficient to go through the
CVS logs once than to try to do the work incrementally. We should
encourage people to write commit messages that are sufficient for the
release notes, but folding the text into release.sgml immediately
doesn't seem all that important.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
How is maintaining another file on every commit going to go over?
If memory serves, we tried this before --- back in the 7.4 devel cycle,
people were supposed to add small entries to release.sgml every time
they committed something worth mentioning in the release notes. This
was not done anywhere near consistently enough to be useful, however,
and so we gave it up. ISTR that we had patch-merging problems too,
because any patch submitters who took it seriously were trying to patch
the same chunk of release.sgml.I tend to agree with Bruce that it's more efficient to go through the
CVS logs once than to try to do the work incrementally. We should
encourage people to write commit messages that are sufficient for the
release notes, but folding the text into release.sgml immediately
doesn't seem all that important.
Another complexity is that when you are going through the logs in 1-3
days, you remember all the information and can adjust things so they are
consistent. I have certain rules of determining what items are worthy,
what are not, and what have to be merged into a single entry. Having
individuals do that is harder.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Then there is the problem that we need consistent wording through the
release notes, so again, I have to wack around some more text.I think this is a strange objection. Many different people have
contributed to the documentation, and yet we've managed to keep the
wording reasonably consistent throughout -- I think we can manage
consistent usage in some release notes. Frankly, the grammar and diction
in the release notes is often not perfect on the first draft anyway, so
there needs to be copy-editing done regardless.Doing it in one pass is the most reliable, and efficient.
Does anyone else have any opinions on this?
Does +1 count?
Joshua D. Drake
-Neil
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/