Re: 7.4 compatibility question - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: 7.4 compatibility question |
Date | |
Msg-id | 200310260440.h9Q4eKl14349@candle.pha.pa.us Whole thread Raw |
In response to | Re: 7.4 compatibility question (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Responses |
Re: 7.4 compatibility question
|
List | pgsql-hackers |
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. -- 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, Pennsylvania19073
pgsql-hackers by date: