Re: Annotated release notes - Mailing list pgsql-docs
From | elein |
---|---|
Subject | Re: Annotated release notes |
Date | |
Msg-id | 20031031125512.F10202@cookie.varlena.com Whole thread Raw |
In response to | Annotated release notes (Bruce Momjian <pgman@candle.pha.pa.us>) |
Responses |
UNSUBSCRIBE
|
List | pgsql-docs |
I included some text about the information schema in this issue of general bits. I also did some documentation of comparison of the changes in the postgresql.conf. Anyone who wants to grab parts of those items in that issue has my permission. I don't have time to re-edit for the release note format. But maybe there is some clarification text you can use. http://cookie.varlena.com:8080/varlena/GeneralBits/48.php elein On Thu, Oct 30, 2003 at 11:59:05PM -0500, Bruce Momjian wrote: > > OK, I have committed changes to release.sgml so most complex entries > have a paragraph describing the change. You can see the result at: > > http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-7-4 > > I need people to check this and help me with the items marked 'bjm'. I > am confused about the proper text for those sections. > > --------------------------------------------------------------------------- > > Tatsuo Ishii wrote: > > > Tatsuo Ishii wrote: > > > > > I've been pushing this agenda for a few releases now, but some people have > > > > > been, er, boycotting it. I think, too, that release notes *must* be > > > > > written incrementally at the same time that the feature change is made. > > > > > This is the only way we can get accurate and complete release notes, and > > > > > the descriptions could even include some context, some motivations, etc. > > > > > We have release cycles of 10 months, and there is no way we can make > > > > > sensible release notes by gathering individual commit messages over that > > > > > period of time. Heck, ECPG has a full Informix compatibility mode and > > > > > there is no mention of that anywhere, because there was no commit "Add > > > > > Informix mode." > > > > > > > > > > I suggest we just do it like the documentation: If you don't document it, > > > > > it doesn't exist. If you don't write a line for the release notes, it > > > > > doesn't exist either. > > > > > > > > I tend to agree it. For every release I and my colleague have been > > > > working on creating detailed release notes (of course in Japanese), > > > > otherwise we cannot tell people what are changed, added or fixed since > > > > there is little info in the official release note. This is painful > > > > since we have to dig into the mail archives and cvs commit messages to > > > > look for what each item of the official release note actually > > > > means. These work take at least 2 to 3 weeks with several people > > > > involved. The hardest part is what are fixed. The only useful > > > > information seems to be the cvs commit messages, however typical > > > > messages are something like "see recent discussions in the mail > > > > archive for more details". This is not very helpful at least for > > > > me. Once I proposed that we add a sequence number to each mail and the > > > > commit messages point to the number. This way we could easily trace > > > > what are the bug report and what are the actual intention for the > > > > fix. For some reason noboy was interested in. Maybe this is due to > > > > "coulture gap"... (In Japan giving a sequence number to each mail in > > > > mailing lists is quite common). > > > > > > OK, if Tatsuo and SRA are having problems, I have to address it. I can > > > supply a more detailed list to Tatsuo/SRA, or I can beef up the release > > > notes to contain more information. Seems some in the community would > > > like to have this detail so I might as well do it and have it in the > > > official docs. One idea would be to add a section at the bottom of the > > > release notes that goes into detail on changes listed in the release > > > notes above --- that way, people can still skim the 300-line release > > > notes, and if they want detailed information about the optimizer changes > > > or subtle pg_dump fixes, that will be at the bottom. > > > > > > How does that sound? I can start on this for 7.4 next week. It > > > basically means going through the CVS logs again and pulling out > > > additional details. > > > > Sounds good. However this kind of information could become huge and I > > am afraid it does not suite well in the official docs in the source > > tree. I think putiing it in somewhere in a web site (maybe > > http://developer.postgresql.org/?) might be more appropreate. > > What do you think? > > -- > > Tatsuo Ishii > > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
pgsql-docs by date: