Thread: 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@agliodbs.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@gmx.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 HaganderSelf: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Peter Eisentraut <peter_e@gmx.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@gmx.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@gmx.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@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.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@gmail.com> writes:
> On Tue, Aug 4, 2009 at 10:48 AM, Tom Lane<tgl@sss.pgh.pa.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@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Aug 4, 2009 at 10:48 AM, Tom Lane<tgl@sss.pgh.pa.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@gmail.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@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.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@gmx.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@momjian.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@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
Bruce Momjian <bruce@momjian.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@sss.pgh.pa.us> wrote: > we need something that is alphanumerically less than "beta". antebeta1? Then, each commit-fest, we up the ante.... -Kevin
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.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@sss.pgh.pa.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@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
"Joshua D. Drake" <jd@commandprompt.com> wrote: >> Tom Lane <tgl@sss.pgh.pa.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@agliodbs.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
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@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
On Wed, 2009-08-05 at 16:34 -0500, Kevin Grittner wrote: > Tom Lane <tgl@sss.pgh.pa.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@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
Robert Haas wrote: > On Wed, Aug 5, 2009 at 6:59 PM, Josh Berkus<josh@agliodbs.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@momjian.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@momjian.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@momjian.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@momjian.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