Re: Release note trimming: another modest proposal
От | Jonathan S. Katz |
---|---|
Тема | Re: Release note trimming: another modest proposal |
Дата | |
Msg-id | 9FBD8BD2-F2F3-4618-A304-DEE93007EDBB@postgresql.org обсуждение исходный текст |
Ответ на | Re: Release note trimming: another modest proposal (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Release note trimming: another modest proposal
|
Список | pgsql-docs |
> On Aug 6, 2018, at 3:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > "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. Attached is a (rough) working copy of the patch to pgweb. It can: - Extract the release notes from the docload and puts them into their own table - Display the release notes via pgweb akin to earlier screenshots It needs: - The notes actually exposed in the navigation tree - Review how some of the xrefs are translated (esp. non-release ones) - Dependency on all major versions being cataloged in our “Version” table on pgweb, which currently we do not do - Magnus review, as to do this I introduced a new Python dependency I was able to successfully load all of the release notes from the 10.4 tarball and spot checked view several different major/minor version combinations. It’s not near production ready, but wanted to demonstrate that it would not be too hard to get this done. Jonathan
Вложения
В списке pgsql-docs по дате отправления: