Thread: 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 notes > > 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 ;-) 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 notes > > > > 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 ;-) > > 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 notes >>> >>> 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 ;-) >> 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 solutionssince 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 notes >>> >>> 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 ;-) >>> >> 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
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.
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
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? > > http://www.postgresql.org/docs/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 solutionssince 1997 http://www.commandprompt.com/
Tom Lane wrote: > 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. That could be annoying, yes. I'm not sure how serious a problem it would be in practice -- we could always adopt workarounds like allowing release note additions anywhere within a section, rather than only at the end. It might actually be better to cluster related changes within a given section of the release notes, anyway. > 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. I think the amount of total work required is probably pretty similar, but incremental updates have several advantages. The work required is distributed among many people, which reduces the "bus factor" of the process. Incremental updates would also remove a significant task from the beta process, because most of the work would be done during the development cycle. As discussed earlier[1], I think the resulting release notes would also be more comprehensive and discuss issues in more depth, because they would be written while the details of the change are fresh in the developer's mind. > 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. Adding the text to release.sgml immediately would also make it more accessible to users, which I think would clearly be a Good Thing. -Neil [1] http://archives.postgresql.org/pgsql-hackers/2006-09/msg00615.php
Bruce Momjian wrote: > Also, we are having trouble getting enough people to review/commit. > Does adding an extra step discourage them even further? I think if you are committing a patch, you should have a clear idea of what the patch does and what its broader impact on the system will be. Summarizing that information in a release note entry is not too much of an additional burden, I think: a committer *ought* to include some similar text in the CVS commit log message anyway. > How is maintaining another file on every commit going to go over? Well, it would clearly not be on every commit: most commits don't warrant a mention in the release notes. If committers think that this burden is too much to bear, please speak up. -Neil
Bruce Momjian wrote: > 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. Well, I think it would certainly make sense to have some guidelines about how release note entries ought to be written and what sort of changes they ought to describe. Given guidelines and plenty of post-commit copy-editing, I don't think it would be hard to produce a high-quality document. -Neil
Neil Conway <neilc@samurai.com> writes:
> Bruce Momjian wrote:
>> How is maintaining another file on every commit going to go over?
> Well, it would clearly not be on every commit: most commits don't
> warrant a mention in the release notes. If committers think that this
> burden is too much to bear, please speak up.
Well, I'm willing to (and I think usually have) put release-note-grade
descriptions into commit log messages, but I'm not willing to add "edit
release.sgml" to the already long process, for two basic reasons:
* it'd make release.sgml into a commit bottleneck --- if everyone is
doing it this way, everyone's local copy of the file would be constantly
out of date, and merge conflicts would be an everyday problem.
* correct SGML markup is a PITA.
If *someone else* wants to troll the commit logs every so often and make
entries into release.sgml, that's fine with me. But I don't have the
bandwidth.
regards, tom lane
Tom Lane wrote: > If *someone else* wants to troll the commit logs every so often and make > entries into release.sgml, that's fine with me. But I don't have the > bandwidth. > > > IIRC this was suggested upthread as a task that might be suitable for some people who are less on the critical path than you and Bruce. I agree that we don't want to add to the burden already on the committers. If anything, the reverse. cheers andrew
Tom Lane <tgl@sss.pgh.pa.us> writes: > Well, I'm willing to (and I think usually have) put release-note-grade > descriptions into commit log messages, but I'm not willing to add "edit > release.sgml" to the already long process, for two basic reasons: > > * it'd make release.sgml into a commit bottleneck --- if everyone is > doing it this way, everyone's local copy of the file would be constantly > out of date, and merge conflicts would be an everyday problem. > > * correct SGML markup is a PITA. > > If *someone else* wants to troll the commit logs every so often and make > entries into release.sgml, that's fine with me. But I don't have the > bandwidth. Well we could make it "edit release.txt" which someone will fix up and turn into release.sgml later instead. I think if you put a big enough separator between entries, say two black lines, two dashes, and two more blank lines, it wouldn't even cause merge conflicts if it failed -- it would just insert the new entry in the "wrong" place which wouldn't really matter. Or you could have a release-notes directory and create a small text file in there for each major patch. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Gregory Stark <stark@enterprisedb.com> writes:
> Well we could make it "edit release.txt" which someone will fix up and turn
> into release.sgml later instead.
> I think if you put a big enough separator between entries, say two black
> lines, two dashes, and two more blank lines, it wouldn't even cause merge
> conflicts if it failed -- it would just insert the new entry in the "wrong"
> place which wouldn't really matter.
> Or you could have a release-notes directory and create a small text file in
> there for each major patch.
Andrew had the correct perspective on this: if someone wants a different
release note process, and is willing to expend their *own* cycles on it,
go to it. If the intention is to try to force the existing committers
to expend extra effort for a process change they do not particularly
believe in, don't be surprised by a lack of cooperation.
regards, tom lane
Tom Lane wrote: > Neil Conway <neilc@samurai.com> writes: > > Bruce Momjian wrote: > >> How is maintaining another file on every commit going to go over? > > > Well, it would clearly not be on every commit: most commits don't > > warrant a mention in the release notes. If committers think that this > > burden is too much to bear, please speak up. > > Well, I'm willing to (and I think usually have) put release-note-grade > descriptions into commit log messages, but I'm not willing to add "edit > release.sgml" to the already long process, for two basic reasons: > > * it'd make release.sgml into a commit bottleneck --- if everyone is > doing it this way, everyone's local copy of the file would be constantly > out of date, and merge conflicts would be an everyday problem. > > * correct SGML markup is a PITA. > > If *someone else* wants to troll the commit logs every so often and make > entries into release.sgml, that's fine with me. But I don't have the > bandwidth. That is pretty much my objection, even though I have to spend the days to create release.sgml. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +