Re: documentation is now XML - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: documentation is now XML
Date
Msg-id CAB7nPqRRCu6OtU81BSPDD1Zt3VVK5t2gS0Qq_PV0QZwgwHTq_g@mail.gmail.com
Whole thread Raw
In response to Re: documentation is now XML  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Nov 24, 2017 at 5:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> The documentation sources are now DocBook XML, not SGML.  (The files are
>> still named *.sgml.  That's something to think about separately.)
>
> I think we should have a discussion about whether it'd be smart
> to convert the back branches' documentation to XML as well.
>
> The main reason that I want to consider this is that back-patching
> documentation fixes is going to be a huge problem if we don't.

Things like c29c578 and 1ff01b3 only found their way on HEAD. There is
a bit of work needed here for back-branches. At the end I would vote
for having consistent documentation on all active branches.

> Using the same doc-building toolchain across all branches seems like a win
> as well.  You could argue that switching build requirements in a minor
> release is unfriendly to packagers; but those who build their own docs
> have already had to adapt to the xsltproc/fop toolchain for v10, so
> standardizing on that for 9.3-9.6 as well doesn't seem like it complicates
> their lives.  (Possibly we should canvass opinions on pgsql-packagers to
> be sure of that.)

My own packaging is going to need some tweaks as well, but there is
nothing difficult. A discussion is definitely deserved on -packagers,
all don't have the same toolchain set.
-- 
Michael


pgsql-hackers by date:

Previous
From: Ildus Kurbangaliev
Date:
Subject: Re: [HACKERS] Custom compression methods
Next
From: Alexander Korotkov
Date:
Subject: Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)?