Re: Alpha Releases: Docs?

Peter,

There's another question for alpha releases: are we going to build docs?
Either for www.postgresql.org, or for PGDATA/docs?

I think we need some kind of docs up, otherwise we'll get little actual
testing. As previously discussed, building the docs yourself from pure
source involves several complicated dependancies which aren't available
on all platforms.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

Josh Berkus wrote:

> I think we need some kind of docs up, otherwise we'll get little
> actual testing. As previously discussed, building the docs yourself
> from pure source involves several complicated dependancies which
> aren't available on all platforms.

Are we going to ship ChangeLog files or some such, giving that we're not
going to have release notes?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

> Are we going to ship ChangeLog files or some such, giving that we're not
> going to have release notes?

I still think we should be doing release notes for the Alphas. It will
limit the pain of doing release notes for the final release; they'll be
done already except formatting.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> Are we going to ship ChangeLog files or some such, giving that we're not
>> going to have release notes?

> I still think we should be doing release notes for the Alphas.

Are you volunteering?

regards, tom lane

Josh Berkus wrote:
>
>> Are we going to ship ChangeLog files or some such, giving that we're not
>> going to have release notes?
>
> I still think we should be doing release notes for the Alphas. It
> will limit the pain of doing release notes for the final release;
> they'll be done already except formatting.
>

We are making more work for ourselves for very little benefit, ISTM.
Unless we make the alpha process very lightweight indeed, I think it
will be a net negative.

cheers

andrew

> Are you volunteering?

Maybe; is there a template where I can access it?

Robert pointed out I ought to get involved anyway for 8.5 so that we can
stop having separate "release notes" and "public" versions of the new
features.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On Monday 03 August 2009 23:08:51 Josh Berkus wrote:
> There's another question for alpha releases: are we going to build docs?

Yes, absolutely. I'm working on making the documentation build part of the
tarball build procedure.

> Either for www.postgresql.org, or for PGDATA/docs?

The web team has to figure out whether putting the docs on the web site is
worthwhile. We already have the developer docs that are rebuild on every
check-in.

On Monday 03 August 2009 23:13:27 Alvaro Herrera wrote:
> Josh Berkus wrote:
> > I think we need some kind of docs up, otherwise we'll get little
> > actual testing. As previously discussed, building the docs yourself
> > from pure source involves several complicated dependancies which
> > aren't available on all platforms.
>
> Are we going to ship ChangeLog files or some such, giving that we're not
> going to have release notes?

There will still be release notes. They might not be as polished as the final
ones, but there will be a list of new things, at least.

On Tue, Aug 4, 2009 at 16:06, Peter Eisentraut<peter_e(at)gmx(dot)net> wrote:
> On Monday 03 August 2009 23:08:51 Josh Berkus wrote:
> The web team has to figure out whether putting the docs on the web site is
> worthwhile.  We already have the developer docs that are rebuild on every
> check-in.

As long as the HTML files are available, we can make this happen. We
don't have the website servers set up with the full build tools, and
we don't want that :-) It is probably not going to be a terrible
amount of work, so if we are going to actually push for people to do
serious testing on the alpha releases, we should definitely get the
docs up on the website.

I don't think we should keep an archive of "old alphas" though -
that's going to leave us with insane amounts of documentation sets.
But we could have a /docs/alpha/ which would hold the latest released
alpha.

--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On Monday 03 August 2009 23:13:27 Alvaro Herrera wrote:
>> Are we going to ship ChangeLog files or some such, giving that we're not
>> going to have release notes?

> There will still be release notes. They might not be as polished as the final
> ones, but there will be a list of new things, at least.

That would be great, but who's going to do them?

regards, tom lane

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On Monday 03 August 2009 23:13:27 Alvaro Herrera wrote:
> >> Are we going to ship ChangeLog files or some such, giving that we're not
> >> going to have release notes?
>
> > There will still be release notes. They might not be as polished as the final
> > ones, but there will be a list of new things, at least.
>
> That would be great, but who's going to do them?

It's easy, just cvs2cl and paste that in a large <pre> block.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On Tuesday 04 August 2009 17:48:12 Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On Monday 03 August 2009 23:13:27 Alvaro Herrera wrote:
> >> Are we going to ship ChangeLog files or some such, giving that we're not
> >> going to have release notes?
> >
> > There will still be release notes. They might not be as polished as the
> > final ones, but there will be a list of new things, at least.
>
> That would be great, but who's going to do them?

I can do it. Perhaps Josh wants to get involved.

On Tue, Aug 4, 2009 at 10:48 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On Monday 03 August 2009 23:13:27 Alvaro Herrera wrote:
>>> Are we going to ship ChangeLog files or some such, giving that we're not
>>> going to have release notes?
>
>> There will still be release notes.  They might not be as polished as the final
>> ones, but there will be a list of new things, at least.
>
> That would be great, but who's going to do them?

I think the question is "who are you going to allow to do them?". I
sort of get the impression that you and Bruce have a love-hate
relationship with the release notes. On the one hand, they're a huge
time sink. On the other hand, it feels like you're not quite ready to
turn them over to anyone else. I feel like there have been some
previous offers of help (including by me) that either weren't an offer
to do quite the right thing or the offer was made at the wrong stage
of the process. I believe you told me on one occasion that they had
to all be written by a single person so that they'd be consistent...
but then, even though Bruce did the initial draft of the release
notes, you did most of the updating as we got closer to release and
more things were committed, so apparently it wasn't that critical for
one person to do it all after all.

For alpha, I think a dump of the CVS commit logs is fine if there's
not a better option. That's what Peter originally proposed, and
there's no reason to change now. But I suspect that it might be
possible to find someone who would be willing to do more than that if
they were treated nicely. For example, if someone volunteers to help
with this now, will their work be thrown out and redone by you and
Bruce "the right way" when the actual release arrives? Or will we
just revise and extend that work throughout the release cycle?

If you want to be rid of this task, then help some other people to do
it and do it well. If you want to keep doing it yourself, then dump
the CVS logs into the alpha release notes and call it good.

...Robert

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Aug 4, 2009 at 10:48 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> That would be great, but who's going to do them?

> I think the question is "who are you going to allow to do them?".

You misread that entirely. What I was pointing out was that we didn't
have a volunteer to expend the nontrivial amount of time required to
do nice notes. If you're volunteering, step right up.

(If "cvs2cl dump" is the best we can do, so be it; but I predict it
will put off a lot of potential testers. The commit messages have
always been written by hackers for hackers, not for end users.)

regards, tom lane

On Tue, Aug 4, 2009 at 11:44 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Aug 4, 2009 at 10:48 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> That would be great, but who's going to do them?
>
>> I think the question is "who are you going to allow to do them?".
>
> You misread that entirely.  What I was pointing out was that we didn't
> have a volunteer to expend the nontrivial amount of time required to
> do nice notes.  If you're volunteering, step right up.

I'm willing to help if these are "8.5 release notes in process". I'm
not willing to help if they are "alpha release notes that will be
thrown away afterwards". Which is it?

...Robert

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I'm willing to help if these are "8.5 release notes in process". I'm
> not willing to help if they are "alpha release notes that will be
> thrown away afterwards". Which is it?

That depends largely on what they look like when we get to beta,
I imagine. Are you asking for a guarantee that no one will edit
your deathless prose?

Traditionally one of the main time sinks involved in making the release
notes has been trying to give them a uniform voice, categorizing them
sensibly, weighting the space given to different topics in a way that
seems to make sense in hindsight, etc. I'd be rather surprised if notes
prepared piecemeal over a series of alpha releases didn't need work of
that sort when we get to the end. That doesn't mean the work would be
"thrown away", but it does mean it's likely to get edited.

regards, tom lane

On Tue, Aug 4, 2009 at 12:01 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I'm willing to help if these are "8.5 release notes in process".  I'm
>> not willing to help if they are "alpha release notes that will be
>> thrown away afterwards".  Which is it?
>
> That depends largely on what they look like when we get to beta,
> I imagine.  Are you asking for a guarantee that no one will edit
> your deathless prose?

Not at all. Don't misunderstand me here: what I was worried about
(and maybe it's without any justification) is that you and/or Bruce
have ideas about how this has to be done that are so specific that
it's not even worth anyone else making an attempt. If that were the
case, then I wouldn't be very interested in working on it.

Now, on the other hand, if doing some work now incrementally over the
next couple of alpha releases will not only produce good release notes
for those alpha releases but also streamline the process of putting
together release notes for beta/final, then it sounds like a
worthwhile investment of time. In the 8.4 release cycle, this was one
of the things that held us up a bit (not a huge amount, but a bit):
all the work was done at the end, and there was a lot to do. If we
can make a start on this early, and if the start is good enough that
it requires incremental changes rather than "rm -f" then that seems
like a pretty good idea.

> Traditionally one of the main time sinks involved in making the release
> notes has been trying to give them a uniform voice, categorizing them
> sensibly, weighting the space given to different topics in a way that
> seems to make sense in hindsight, etc.  I'd be rather surprised if notes
> prepared piecemeal over a series of alpha releases didn't need work of
> that sort when we get to the end.  That doesn't mean the work would be
> "thrown away", but it does mean it's likely to get edited.

OK, great. That sounds like exactly the sort of editing that I would
expect to be necessary.

...Robert

On Tuesday 04 August 2009 18:52:06 Robert Haas wrote:
> I'm willing to help if these are "8.5 release notes in process". I'm
> not willing to help if they are "alpha release notes that will be
> thrown away afterwards". Which is it?

I was working on the latter assumption.

I have some reservations about the former approach. It would basically commit
us right now to having a consistent set of volunteers available every two
months within specific 1-2 day spans. Which is the sort of thing I wanted to
avoid. But if we have that commitment, then go for it.

> I have some reservations about the former approach. It would basically commit
> us right now to having a consistent set of volunteers available every two
> months within specific 1-2 day spans. Which is the sort of thing I wanted to
> avoid. But if we have that commitment, then go for it.

Can we hear from Bruce on this, as well? I think Robert is right to be
concerned that his work will be thrown away; so am I.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

Magnus,

> I don't think we should keep an archive of "old alphas" though -
> that's going to leave us with insane amounts of documentation sets.
> But we could have a /docs/alpha/ which would hold the latest released
> alpha.

Yes, that's perfect.

For that matter, for the release notes, I wasn't planning to have a
seperate set for every alpha. I was thinking of just creating a
*cumulative* set, with the new items for the current alpha flagged somehow.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On Tue, Aug 4, 2009 at 1:19 PM, Peter Eisentraut<peter_e(at)gmx(dot)net> wrote:
> On Tuesday 04 August 2009 18:52:06 Robert Haas wrote:
>> I'm willing to help if these are "8.5 release notes in process".  I'm
>> not willing to help if they are "alpha release notes that will be
>> thrown away afterwards".  Which is it?
>
> I was working on the latter assumption.
>
> I have some reservations about the former approach.  It would basically commit
> us right now to having a consistent set of volunteers available every two
> months within specific 1-2 day spans.  Which is the sort of thing I wanted to
> avoid.  But if we have that commitment, then go for it.

Yeah, the timing of the alpha releases could make this tricky. I'm
not sure if there's a way to work around that, or if we should just
give up and keep doing it the way that we have in the past.

I would like to think that the timing wouldn't need to be quite as
tight as what you are supposing. For example, is it really too early
to start working on the release notes for alpha1 now, or say at the
end of the week? If work were started on 8/7, there would still be 8
days left before official end-of-CommitFest, and presumably the
release of alpha wouldn't be until a few days after that, yet we'd
have a pretty good idea what was going to be in there.

Also, to be quite frank, I don't care that much about alpha releases.
What I care about is production releases. Helping with the release
notes for alpha is a means to an end. So it seems to me that, if
necessary, we could do something quick-and-dirty to get out the door,
and then we can work on patching them up over time. So the release
notes for features added in the latest alpha might be a little rougher
than the ones for earlier alphas (but maybe still better than, here's
the CVS log, have fun).

What I would like to avoid is a situation where we're basically ready
to go with beta and Bruce says, "Hold on, everybody, it's going to
take another two weeks while I plow through 600 commit messages." I
have a theory that that work can be spread out and much of it done in
advance and not necessarily by Bruce. However, that theory has yet to
be tested, and the committers (principally Tom and Bruce) have to be
open to it for it to have any chance of success.

...Robert

> What I would like to avoid is a situation where we're basically ready
> to go with beta and Bruce says, "Hold on, everybody, it's going to
> take another two weeks while I plow through 600 commit messages." I
> have a theory that that work can be spread out and much of it done in
> advance and not necessarily by Bruce. However, that theory has yet to
> be tested, and the committers (principally Tom and Bruce) have to be
> open to it for it to have any chance of success.

I just talked to Bruce on IM, and he said that he would NOT use any
release notes we produce no matter how good they are.

Therefore, us trying to help by producing alpha release notes is a waste
of time; I won't bother.

Instead, I'll just write up a brief, informal user-friendly list of
features and changes, and we can release that combined with the cvslog.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

Josh Berkus wrote:
>
> > What I would like to avoid is a situation where we're basically ready
> > to go with beta and Bruce says, "Hold on, everybody, it's going to
> > take another two weeks while I plow through 600 commit messages." I
> > have a theory that that work can be spread out and much of it done in
> > advance and not necessarily by Bruce. However, that theory has yet to
> > be tested, and the committers (principally Tom and Bruce) have to be
> > open to it for it to have any chance of success.
>
> I just talked to Bruce on IM, and he said that he would NOT use any
> release notes we produce no matter how good they are.
>
> Therefore, us trying to help by producing alpha release notes is a waste
> of time; I won't bother.
>
> Instead, I'll just write up a brief, informal user-friendly list of
> features and changes, and we can release that combined with the cvslog.

Sorry I didn't chime in yesterday; I am still 3.7k community emails
backlogged.

As far as the release notes, I think we would have to have proof that
the alpha-generated release notes are as good or close to the quality of
the release notes using the current process. If they are, we can use
them for 8.6, or even for 8.5 if the quality is similar, but we can't
know that without creating identical release notes for 8.5 and comparing
them, to make sure the alpha process has not missed any items, etc.
What we don't want to do is switch to a new process for creating the
release notes, and only later realize we missed stuff or there was some
subtle change that caused inaccuracies. Remember, we are database guys. :-)

This is going to follow the same process as the patch application/commit
fest changes; I am glad to give up the burden of creating the release
notes (and I think Tom is too) but we have to have something as good or
better before making the switch. This happened for the patch
application process, and it might happen with the release notes too, but
we have to do duplicate work while we are testing out the new system.

(I frankly think the economies of scale
(http://en.wikipedia.org/wiki/Economy_of_scale) for the release notes
are going to make creating them during alpha much harder, but I am
willing to be proven wrong. I am not willing to expend effort to create
alpha release notes because it is too hard to fit into my workload.)

As far as the alpha releases, I am still worried about the use of the
word "alpha". I am worried someone is going to look at 8.4alpha1 and
think that represents most of the features that will be in 8.5final, and
will think the Postgres project is losing momentum. I would much rather
they be called Commit Feast 1 (CF1), or something like that.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

On Wed, 2009-08-05 at 17:11 -0400, Bruce Momjian wrote:
> Josh Berkus wrote:

> As far as the alpha releases, I am still worried about the use of the
> word "alpha". I am worried someone is going to look at 8.4alpha1 and
> think that represents most of the features that will be in 8.5final, and
> will think the Postgres project is losing momentum. I would much rather
> they be called Commit Feast 1 (CF1), or something like that.

An Alpha release should be feature complete.

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> As far as the alpha releases, I am still worried about the use of the
> word "alpha". I am worried someone is going to look at 8.4alpha1 and
> think that represents most of the features that will be in 8.5final, and
> will think the Postgres project is losing momentum. I would much rather
> they be called Commit Feast 1 (CF1), or something like that.

I think that's easily dealt with by a suitable notice at the top of
the alpha release notes (or whatever substitutes for them).

As was discussed at the PGCon meeting, we can't use "cfN" because that
doesn't sort before "betaN", which would confuse the heck out of various
package management services. I'm not wedded to the term "alpha", but
we need something that is alphanumerically less than "beta".

regards, tom lane

> As far as the alpha releases, I am still worried about the use of the
> word "alpha".  I am worried someone is going to look at 8.4alpha1 and
> think that represents most of the features that will be in 8.5final, and
> will think the Postgres project is losing momentum.  I would much rather
> they be called Commit Feast 1 (CF1), or something like that.
>

milestone ?

regards
Marcin Mańk

Bruce Momjian wrote:
> I would much rather
> they be called Commit Feast 1 (CF1), or something like that.
>
>

ITYM "Fest", although sometimes we make a meal of it ;-)

cheers

andrew

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> we need something that is alphanumerically less than "beta".

antebeta1?

Then, each commit-fest, we up the ante....

-Kevin

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> we need something that is alphanumerically less than "beta".

> antebeta1?

> Then, each commit-fest, we up the ante....

rotfl...

Actually just "ante1" would work better for that joke.

regards, tom lane

On Wed, 2009-08-05 at 16:34 -0500, Kevin Grittner wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > we need something that is alphanumerically less than "beta".
>
> antebeta1?
>
> Then, each commit-fest, we up the ante....

1stCF09
2ndCF09
3rdCF09

>
> -Kevin
>
--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

"Joshua D. Drake" <jd(at)commandprompt(dot)com> wrote:
>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> > we need something that is alphanumerically less than "beta".

> 1stCF09
> 2ndCF09
> 3rdCF09

Ah, but those would sort higher than letters in EBCDIC....

-Kevin

Bruce,

> As far as the release notes, I think we would have to have proof that
> the alpha-generated release notes are as good or close to the quality of
> the release notes using the current process. If they are, we can use
> them for 8.6, or even for 8.5 if the quality is similar, but we can't
> know that without creating identical release notes for 8.5 and comparing
> them, to make sure the alpha process has not missed any items, etc.

I can't speak for Robert or Peter, but for me this gives me exactly zero
incentive to bother. If you're just going to do the same amount of work
anyway ... and potentially delay the release by just as much ... then
there's really no point on me spending my nights and weekends wrestling
with SGML formatting. I'll leave it to you.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On Wed, Aug 5, 2009 at 6:59 PM, Josh Berkus<josh(at)agliodbs(dot)com> wrote:
>> As far as the release notes, I think we would have to have proof that
>> the alpha-generated release notes are as good or close to the quality of
>> the release notes using the current process.  If they are, we can use
>> them for 8.6, or even for 8.5 if the quality is similar, but we can't
>> know that without creating identical release notes for 8.5 and comparing
>> them, to make sure the alpha process has not missed any items, etc.
>
> I can't speak for Robert or Peter, but for me this gives me exactly zero
> incentive to bother.  If you're just going to do the same amount of work
> anyway ... and potentially delay the release by just as much ... then
> there's really no point on me spending my nights and weekends wrestling
> with SGML formatting.  I'll leave it to you.

I think I am in agreement. Parsing Bruce's words carefully, he seems
to be saying that the only way to determine whether the release notes
are of sufficient quality is to repeat the whole process of release
note generation ab initio to determine whether what has been produced
is good enough. Presumably this would be followed by some comparison
of the two work products (by a panel of impartial judges?).

I can't believe this is necessary. It ought to be possible with
careful bookkeeping to make it easy to verify that every commit has
been either included or intentionally omitted. The obvious system
that occurs to me is to track the git hash of each commit and the
release note text associated with it, but I am sure there are other
unique identifiers that could equally well be used. Once you've
verified that, then the only remaining issue is the actual quality of
the work product, and I would think that it could be much faster to
edit someone else's work than to do the whole thing over. Peter and
Josh both have excellent written communication skills, and I like to
think that I do as well; I would think that the necessary work would
be more on the order of fine-tuning than a wholesale rewrite.

That having been said, I am not going to spend a lot of time trying to
push water up a hill.

...Robert

Robert Haas wrote:
> On Wed, Aug 5, 2009 at 6:59 PM, Josh Berkus<josh(at)agliodbs(dot)com> wrote:
> >> As far as the release notes, I think we would have to have proof that
> >> the alpha-generated release notes are as good or close to the quality of
> >> the release notes using the current process. ?If they are, we can use
> >> them for 8.6, or even for 8.5 if the quality is similar, but we can't
> >> know that without creating identical release notes for 8.5 and comparing
> >> them, to make sure the alpha process has not missed any items, etc.
> >
> > I can't speak for Robert or Peter, but for me this gives me exactly zero
> > incentive to bother. ?If you're just going to do the same amount of work
> > anyway ... and potentially delay the release by just as much ... then
> > there's really no point on me spending my nights and weekends wrestling
> > with SGML formatting. ?I'll leave it to you.
>
> I think I am in agreement. Parsing Bruce's words carefully, he seems
> to be saying that the only way to determine whether the release notes
> are of sufficient quality is to repeat the whole process of release
> note generation ab initio to determine whether what has been produced
> is good enough. Presumably this would be followed by some comparison
> of the two work products (by a panel of impartial judges?).
>
> I can't believe this is necessary. It ought to be possible with
> careful bookkeeping to make it easy to verify that every commit has
> been either included or intentionally omitted. The obvious system
> that occurs to me is to track the git hash of each commit and the
> release note text associated with it, but I am sure there are other
> unique identifiers that could equally well be used. Once you've
> verified that, then the only remaining issue is the actual quality of
> the work product, and I would think that it could be much faster to
> edit someone else's work than to do the whole thing over. Peter and
> Josh both have excellent written communication skills, and I like to
> think that I do as well; I would think that the necessary work would
> be more on the order of fine-tuning than a wholesale rewrite.
>
> That having been said, I am not going to spend a lot of time trying to
> push water up a hill.

I would love to get out of the release-note-writing business, but I
can't imagine how such a document could be written incrementally, so it
is logical that I would want some kind of test to see that the method I
didn't think would work would actually work.

I could state right now that I will not do any 8.5 release notes and
force folks to cobble something together, and hope it works, but that is
hardly repsonsible.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce,

> I would love to get out of the release-note-writing business, but I
> can't imagine how such a document could be written incrementally, so it
> is logical that I would want some kind of test to see that the method I
> didn't think would work would actually work.

What about Robert's suggested method of simply checking the incremental
version against the commit logs? Then you'd only be writing what was
actually missed, rather than writing everything and then checking it.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

Josh Berkus wrote:
> Bruce,
>
> > I would love to get out of the release-note-writing business, but I
> > can't imagine how such a document could be written incrementally, so it
> > is logical that I would want some kind of test to see that the method I
> > didn't think would work would actually work.
>
> What about Robert's suggested method of simply checking the incremental
> version against the commit logs? Then you'd only be writing what was
> actually missed, rather than writing everything and then checking it.

That seems like more work than just doing the entire thing.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Josh Berkus wrote:
> Bruce,
>
> > I would love to get out of the release-note-writing business, but I
> > can't imagine how such a document could be written incrementally, so it
> > is logical that I would want some kind of test to see that the method I
> > didn't think would work would actually work.
>
> What about Robert's suggested method of simply checking the incremental
> version against the commit logs? Then you'd only be writing what was
> actually missed, rather than writing everything and then checking it.

I don't see why it is a problem to have folks creating incremental
release notes and having me create some for 8.5 to test against? This
is how we have automated other processes --- you do as good a job as I
do and I stop doing the job. It seems it would be me wasting my time to
validate you work, but I am willing to do it.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

On Thu, Aug 6, 2009 at 8:20 PM, Bruce Momjian<bruce(at)momjian(dot)us> wrote:
> Josh Berkus wrote:
>> Bruce,
>>
>> > I would love to get out of the release-note-writing business, but I
>> > can't imagine how such a document could be written incrementally, so it
>> > is logical that I would want some kind of test to see that the method I
>> > didn't think would work would actually work.
>>
>> What about Robert's suggested method of simply checking the incremental
>> version against the commit logs?  Then you'd only be writing what was
>> actually missed, rather than writing everything and then checking it.
>
> I don't see why it is a problem to have folks creating incremental
> release notes and having me create some for 8.5 to test against?  This
> is how we have automated other processes --- you do as good a job as I
> do and I stop doing the job.  It seems it would be me wasting my time to
> validate you work, but I am willing to do it.

Well, to some extent this may boil down to semantics, but keep in mind
that our goal in volunteering is to get the release out the door more
quickly. We need you to be willing to do less work, not more, or at
least find a way to get some of that work out of the critical path of
the release.

...Robert