Re: Release note bloat is getting out of hand

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Release note bloat is getting out of hand
Дата
Msg-id 54D0384A.7080008@BlueTreble.com
обсуждение исходный текст
Ответ на Re: Release note bloat is getting out of hand  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 2/2/15 3:10 PM, Andres Freund wrote:
> On February 2, 2015 9:38:43 PM CET, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Mon, Feb 2, 2015 at 3:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> The existing release notes are not conveniently searchable, for sure;
>>> they're not in a single file, and they don't show up on a single page
>>> on the Web, and I've never seen a PDF-searching tool that didn't
>> suck.
>>> So I'm bemused by Robert's insistence that he wants that format to
>> support
>>> searches.  As I said, I find it far more convenient to search the
>> output
>>> of "git log" and/or src/tools/git_changelog --- I keep text files of
>> those
>>> around for exactly that purpose.
>>
>> I normally search in one of two ways.  Sometimes a grep the sgml;
>> other times, I go to, say,
>> http://www.postgresql.org/docs/devel/static/release-9-4.html and then
>> edit the URL to take me back to 9.3, 9.2, 9.1, etc.
>
> FWIW I the same. Git log is great if you want all detail. But often enough the more condensed format of the release
notesis helpful. Say, a customer has problems after migrating to a new version. It's quite a bit faster to read the
sectionabout incompatibilities than travel through the git log.
 

This wouldn't prevent that; you could still point them to 
http://www.postgresql.org/docs/7.1/static/release-0-01.html

> There's a reason the release notes exist. Given that they're apparently useful, it doesn't seem strange that devs
sometimesread them...
 

Sure, but dev's have any number of other ways to get at this info, and 
in a fashion that's actually *more* useful to them. Several people have 
asked for a single grep-able file, for example. ISTM that keeping such a 
file around in the source (and perhaps in /src instead of /doc) should 
be easy.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0
Следующее
От: Michael Paquier
Дата:
Сообщение: Missing markup in pg_receivexlog.sgml