Re: 7.4 compatibility question

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: 7.4 compatibility question
Дата
Msg-id 3F9BB67C.7020701@dunslane.net
обсуждение исходный текст
Ответ на Re: 7.4 compatibility question  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: 7.4 compatibility question  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers

Bruce Momjian wrote:

>Tatsuo Ishii wrote:
>  
>
>>>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?
>>    
>>
>
>Yes, I had thought about that --- I put something about migrating to 7.3
>on a web page and put the URL in the release notes, and the URL kept
>becoming invalid as they changed web configurations.  I am afraid we
>have to keep this in CVS so we don't lose it over time.
>
>It could be huge.  Current release notes for 7.4 is around 500 lines.  I
>think I could do this in another 500 lines.
>

This is starting to sound awfully like a conventional bug tracking 
system but without the support infrastructure. Why not go the whole 
distance? Then your release notes could give the numbers and headings of 
bugs fixed  (including features added) and those who want more details 
could look at the bug reports. The process could be a whole lot less 
painful than it appears to be right now, I suspect.

cheers

andrew




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kurt Roeckx
Дата:
Сообщение: Re: regression failure with current
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Call for port reports