Re: Release note trimming: another modest proposal

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Release note trimming: another modest proposal
Дата
Msg-id 1620.1533584265@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Release note trimming: another modest proposal  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Ответы Re: Release note trimming: another modest proposal  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Re: Release note trimming: another modest proposal  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-docs
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> On Aug 6, 2018, at 3:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Actually, a concrete reason why that might not be good is that it results
>> in having a single point of failure: once we remove branch N's relnotes
>> from the active branches, the only copy of that data is the one in the
>> archive table the docload script is filling.  Given, say, a bug in the
>> docload script that causes it to overwrite the wrong table entries,
>> can we recover?

> Well, the release notes are still in the git history as well as the tarballs.
> One could always pull an older tarball of PostgreSQL with the full
> release.sgml and load from there.

True ... as long as those older tarballs represent data that our current
workflow can process.  For instance, if we did another documentation
format change (from XML to something else), the older tarballs would
perhaps no longer be useful for this purpose.

On the other hand, it's hard to believe that we'd make such a conversion
without tools to help.  So probably if the situation came up, we could
cobble together something that would allow ingesting the old format.

            regards, tom lane


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

Предыдущее
От: "Jonathan S. Katz"
Дата:
Сообщение: Re: Release note trimming: another modest proposal
Следующее
От: "Jonathan S. Katz"
Дата:
Сообщение: Re: Release note trimming: another modest proposal